24 Dec, 2020
1 commit
-
Add a tracepoint for pause and resume which measures the
duration of time to perform the entire operation, the
cpus acted upon with this event, and the current state
of the active cpu mask. This should be sufficient
for testing pause performance.Bug: 175959069
Change-Id: I9fc269c7d09ac78ec31612d3c552044b72b0e6e3
Signed-off-by: Stephen Dickey
23 Dec, 2020
4 commits
-
f_accessory: fix CTS test stuck since CTS 9.0.
- Refine acc_read() process.The data length that user (test program) wants to read is different
from they really requested. This will cause the test flow stuck on the
2nd or the 3rd transfers in accessory test.
(By connecting 2 phones with CtsVerifier.apk and
CtsVerifierUSBCompanion.apk installed.)Bug: 174729307
Change-Id: I5367c8075ed37534e8bed94b60cc79135ae5aebc
Signed-off-by: Macpaul Lin -
CRYPTO_MD5 is needed to guarantee legacy compatibility with 3gpp
infrastructure. This compat is guaranteed by the vts net tests
which are currently failing due to this missing config.Bug: 171462501
Signed-off-by: Ram Muthiah
Change-Id: Ibb5bff947595058a0970ae8bbd64c5f5eab8ba7d -
Unset CONFIG_DMABUF_HEAPS_SYSTEM from gki_defconfig
so that it can be enabled as a vendor module.This change is intended to allow partners to continue using
device/SoC-specific optimizations in their system heap implementations
when they switch from ION to DMA-BUF heaps. The ION system heap was
built-in and partners were asked to override the system heap ID with
their own if they wanted to override the GKI system heap. This
per-vendor approach to override system heap will no longer be possible
with DMA-BUF heaps since Android S aims to restrict framework access to
DMA-BUF vendor heaps by only letting it access ABI-defined vendor heaps.VTS tests will be created to ensure that the system heap is present
at /dev/dma_heap/system and behaves as expected of the system heap.Bug: 175697666
Bug: 155218010
Bug: 172527615Signed-off-by: Hridya Valsaraju
Change-Id: Id97ed4814517339c69b99f8135e9a66e59d951a9 -
This patch sets CONFIG_DMABUF_HEAPS_SYSTEM to tristate and exports the
symbol dma_heap_get_dev() to allow the DMA-BUF system heap to be a
module.This change is intended to allow partners to continue using
device/SoC-specific optimizations in their system heap implementations
when they switch from ION to DMA-BUF heaps. The ION system heap was
built-in and partners were asked to override the system heap ID with
their own if they wanted to override the GKI system heap. This
per-vendor approach to override system heap will no longer be possible
with DMA-BUF heaps since Android S aims to restrict framework access to
DMA-BUF vendor heaps by only letting it access ABI-defined vendor heaps.VTS tests will be created to ensure that the system heap is present
at /dev/dma_heap/system and behaves as expected of the system heap.Bug: 175697666
Bug: 155218010
Bug: 172527615
Change-Id: Iabb24d9aedde308a9b15509781dd0e6b67353e99
Signed-off-by: Hridya Valsaraju
22 Dec, 2020
20 commits
-
After recent changes to the DWC3 driver, we need the following
symbols in the symbol list.Generated with:
BUILD_CONFIG=common/build.config.db845c build/build_abi.sh -sFixes: 87e01dd37854 ("Revert "ANDROID: db845c_gki.fragment: Drop CONFIG_USB_DWC3 from config frament"")
Signed-off-by: John Stultz
Change-Id: Ifc8b74fe33a040a778d04b77cb68a9e62cb997aa -
seccomp_bpf.c uses unshare(CLONE_NEWPID), which requires CONFIG_PID_NS
to be set.Cc: Kees Cook
Cc: Shuah Khan
Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
Signed-off-by: Mickaël Salaün
Acked-by: Tycho Andersen
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20201202162643.249276-1-mic@digikod.net
(cherry picked from commit 2c07343abd8932200a45ff7b10950e71081e9e77)
Signed-off-by: Jeff Vander Stoep
Bug: 176068146
Change-Id: Ia7724fdb085c964dd8255fbd2457dc0cfc1d4900 -
Buffers that are passed to read_actions_logged() and write_actions_logged()
are in kernel memory; the sysctl core takes care of copying from/to
userspace.Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
Reviewed-by: Tyler Hicks
Signed-off-by: Jann Horn
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/20201120170545.1419332-1-jannh@google.com
(cherry picked from commit fab686eb0307121e7a2890b6d6c57edd2457863d)
Signed-off-by: Jeff Vander Stoep
Change-Id: I378d1eb73ff01928d3255191ed4443cd7b87c720
Bug: 176068146 -
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for xtensa.Signed-off-by: YiFei Zhu
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/79669648ba167d668ea6ffb4884250abcd5ed254.1605101222.git.yifeifz2@illinois.edu
(cherry picked from commit 445247b02342a05b7d528bba6d85d2d418875b69)
Signed-off-by: Jeff Vander Stoep
Bug: 176068146
Change-Id: I7f8ecb0da495552c062e39e1b9bd5ba0aace3b01 -
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for sh.Signed-off-by: YiFei Zhu
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/61ae084cd4783b9b50860d9dedb4a348cf1b7b6f.1605101222.git.yifeifz2@illinois.edu
(cherry picked from commit 4c18bc054bffe415bec9e0edaa9ff1a84c1a6973)
Signed-off-by: Jeff Vander Stoep
Bug: 176068146
Change-Id: I4cdb3b9fda0af5e5d1e4eede11661c828f41aad5 -
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for s390.Signed-off-by: YiFei Zhu
Acked-by: Heiko Carstens
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/a381b10aa2c5b1e583642f3cd46ced842d9d4ce5.1605101222.git.yifeifz2@illinois.edu
(cherry picked from commit c09058eda2654c37fd7ac28c2004c3aae8b988e9)
Signed-off-by: Jeff Vander Stoep
Bug: 176068146
Change-Id: I643cdd2a001f80bd5f6a64298e4a42412d66651e -
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for riscv.Signed-off-by: YiFei Zhu
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/58ef925d00505cbb77478fa6bd2b48ab2d902460.1605101222.git.yifeifz2@illinois.edu
(cherry picked from commit 673a11a7e4152b101bad6851c4e4c34c7c6d6dde)
Signed-off-by: Jeff Vander Stoep
Bug: 176068146
Change-Id: Id527ef5da40301bbdca59d92ed24523959f96707 -
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for powerpc.__LITTLE_ENDIAN__ is used here instead of CONFIG_CPU_LITTLE_ENDIAN
to keep it consistent with asm/syscall.h.Signed-off-by: YiFei Zhu
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/0b64925362671cdaa26d01bfe50b3ba5e164adfd.1605101222.git.yifeifz2@illinois.edu
(cherry picked from commit e7bcb4622ddf4473da6c03fa8423919a568c57dc)
Signed-off-by: Jeff Vander Stoep
Bug: 176068146
Change-Id: I917b30a0c8cc6697513cc7f12bc84691e3166745 -
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for parisc.Signed-off-by: YiFei Zhu
Acked-by: Helge Deller
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/9bb86c546eda753adf5270425e7353202dbce87c.1605101222.git.yifeifz2@illinois.edu
(cherry picked from commit 6aa7923c8737d1f8fd2a06154155d68dec646464)
Signed-off-by: Jeff Vander Stoep
Bug: 176068146
Change-Id: I48ef86a4127b9cc87dff5235ded3733c098db7e1 -
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for csky.Signed-off-by: YiFei Zhu
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/f9219026d4803b22f3e57e3768b4e42e004ef236.1605101222.git.yifeifz2@illinois.edu
(cherry picked from commit 6e9ae6f98809e0d123ff4d769ba2e6f652119138)
Signed-off-by: Jeff Vander Stoep
Bug: 176068146
Change-Id: I1fea89150f06be98ea4ee4357ad441e60aa6589f -
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for arm.Signed-off-by: Kees Cook
(cherry picked from commit 424c9102fa7b2a5c15afe47fd14278c849f4eefb)
Signed-off-by: Jeff Vander Stoep
Change-Id: I90eaafdc43f618ce7dcf76e1cbb8ae1ff542ead9
Bug: 176068146 -
To enable seccomp constant action bitmaps, we need to have a static
mapping to the audit architecture and system call table size. Add these
for arm64.Signed-off-by: Kees Cook
(cherry picked from commit ffde703470b03b1000017ed35c4f90a90caa22cf)
Signed-off-by: Jeff Vander Stoep
Change-Id: Ib21059de0928a61bd76202a67732432e88c5a5f0
Bug: 176068146 -
As part of the seccomp benchmarking, include the expectations with
regard to the timing behavior of the constant action bitmaps, and report
inconsistencies better.Example output with constant action bitmaps on x86:
$ sudo ./seccomp_benchmark 100000000
Current BPF sysctl settings:
net.core.bpf_jit_enable = 1
net.core.bpf_jit_harden = 0
Benchmarking 200000000 syscalls...
129.359381409 - 0.008724424 = 129350656985 (129.4s)
getpid native: 646 ns
264.385890006 - 129.360453229 = 135025436777 (135.0s)
getpid RET_ALLOW 1 filter (bitmap): 675 ns
399.400511893 - 264.387045901 = 135013465992 (135.0s)
getpid RET_ALLOW 2 filters (bitmap): 675 ns
545.872866260 - 399.401718327 = 146471147933 (146.5s)
getpid RET_ALLOW 3 filters (full): 732 ns
696.337101319 - 545.874097681 = 150463003638 (150.5s)
getpid RET_ALLOW 4 filters (full): 752 ns
Estimated total seccomp overhead for 1 bitmapped filter: 29 ns
Estimated total seccomp overhead for 2 bitmapped filters: 29 ns
Estimated total seccomp overhead for 3 full filters: 86 ns
Estimated total seccomp overhead for 4 full filters: 106 ns
Estimated seccomp entry overhead: 29 ns
Estimated seccomp per-filter overhead (last 2 diff): 20 ns
Estimated seccomp per-filter overhead (filters / 4): 19 ns
Expectations:
native ≤ 1 bitmap (646 ≤ 675): ✔️
native ≤ 1 filter (646 ≤ 732): ✔️
per-filter (last 2 diff) ≈ per-filter (filters / 4) (20 ≈ 19): ✔️
1 bitmapped ≈ 2 bitmapped (29 ≈ 29): ✔️
entry ≈ 1 bitmapped (29 ≈ 29): ✔️
entry ≈ 2 bitmapped (29 ≈ 29): ✔️
native + entry + (per filter * 4) ≈ 4 filters total (755 ≈ 752): ✔️[YiFei: Changed commit message to show stats for this patch series]
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/1b61df3db85c5f7f1b9202722c45e7b39df73ef2.1602431034.git.yifeifz2@illinois.edu
(cherry picked from commit 192cf32243ce39af65bd095625aec374b38c03df)
Signed-off-by: Jeff Vander Stoep
Change-Id: Idd30139b4fbb2c06f4b043756bbb09bbacf3b123
Bug: 176068146 -
Provide seccomp internals with the details to calculate which syscall
table the running kernel is expecting to deal with. This allows for
efficient architecture pinning and paves the way for constant-action
bitmaps.Co-developed-by: YiFei Zhu
Signed-off-by: YiFei Zhu
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/da58c3733d95c4f2115dd94225dfbe2573ba4d87.1602431034.git.yifeifz2@illinois.edu
(cherry picked from commit 25db91209a910a0ccf8b093743088d0f4bf5659f)
Signed-off-by: Jeff Vander Stoep
Change-Id: I48a434063e401b27834e4ba37b88a852da51300b
Bug: 176068146 -
SECCOMP_CACHE will only operate on syscalls that do not access
any syscall arguments or instruction pointer. To facilitate
this we need a static analyser to know whether a filter will
return allow regardless of syscall arguments for a given
architecture number / syscall number pair. This is implemented
here with a pseudo-emulator, and stored in a per-filter bitmap.In order to build this bitmap at filter attach time, each filter is
emulated for every syscall (under each possible architecture), and
checked for any accesses of struct seccomp_data that are not the "arch"
nor "nr" (syscall) members. If only "arch" and "nr" are examined, and
the program returns allow, then we can be sure that the filter must
return allow independent from syscall arguments.Nearly all seccomp filters are built from these cBPF instructions:
BPF_LD | BPF_W | BPF_ABS
BPF_JMP | BPF_JEQ | BPF_K
BPF_JMP | BPF_JGE | BPF_K
BPF_JMP | BPF_JGT | BPF_K
BPF_JMP | BPF_JSET | BPF_K
BPF_JMP | BPF_JA
BPF_RET | BPF_K
BPF_ALU | BPF_AND | BPF_KEach of these instructions are emulated. Any weirdness or loading
from a syscall argument will cause the emulator to bail.The emulation is also halted if it reaches a return. In that case,
if it returns an SECCOMP_RET_ALLOW, the syscall is marked as good.Emulator structure and comments are from Kees [1] and Jann [2].
Emulation is done at attach time. If a filter depends on more
filters, and if the dependee does not guarantee to allow the
syscall, then we skip the emulation of this syscall.[1] https://lore.kernel.org/lkml/20200923232923.3142503-5-keescook@chromium.org/
[2] https://lore.kernel.org/lkml/CAG48ez1p=dR_2ikKq=xVxkoGg0fYpTBpkhJSv1w-6BG=76PAvw@mail.gmail.com/Suggested-by: Jann Horn
Signed-off-by: YiFei Zhu
Reviewed-by: Jann Horn
Co-developed-by: Kees Cook
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/71c7be2db5ee08905f41c3be5c1ad6e2601ce88f.1602431034.git.yifeifz2@illinois.edu
(cherry picked from commit 8e01b51a31a1e08e2c3e8fcc0ef6790441be2f61)
Signed-off-by: Jeff Vander Stoep
Change-Id: I5047f7f0d6502e5de6c047743f1053fda3025a6e
Bug: 176068146 -
The overhead of running Seccomp filters has been part of some past
discussions [1][2][3]. Oftentimes, the filters have a large number
of instructions that check syscall numbers one by one and jump based
on that. Some users chain BPF filters which further enlarge the
overhead. A recent work [6] comprehensively measures the Seccomp
overhead and shows that the overhead is non-negligible and has a
non-trivial impact on application performance.We observed some common filters, such as docker's [4] or
systemd's [5], will make most decisions based only on the syscall
numbers, and as past discussions considered, a bitmap where each bit
represents a syscall makes most sense for these filters.The fast (common) path for seccomp should be that the filter permits
the syscall to pass through, and failing seccomp is expected to be
an exceptional case; it is not expected for userspace to call a
denylisted syscall over and over.When it can be concluded that an allow must occur for the given
architecture and syscall pair (this determination is introduced in
the next commit), seccomp will immediately allow the syscall,
bypassing further BPF execution.Each architecture number has its own bitmap. The architecture
number in seccomp_data is checked against the defined architecture
number constant before proceeding to test the bit against the
bitmap with the syscall number as the index of the bit in the
bitmap, and if the bit is set, seccomp returns allow. The bitmaps
are all clear in this patch and will be initialized in the next
commit.When only one architecture exists, the check against architecture
number is skipped, suggested by Kees Cook [7].[1] https://lore.kernel.org/linux-security-module/c22a6c3cefc2412cad00ae14c1371711@huawei.com/T/
[2] https://lore.kernel.org/lkml/202005181120.971232B7B@keescook/T/
[3] https://github.com/seccomp/libseccomp/issues/116
[4] https://github.com/moby/moby/blob/ae0ef82b90356ac613f329a8ef5ee42ca923417d/profiles/seccomp/default.json
[5] https://github.com/systemd/systemd/blob/6743a1caf4037f03dc51a1277855018e4ab61957/src/shared/seccomp-util.c#L270
[6] Draco: Architectural and Operating System Support for System Call Security
https://tianyin.github.io/pub/draco.pdf, MICRO-53, Oct. 2020
[7] https://lore.kernel.org/bpf/202010091614.8BB0EB64@keescook/Co-developed-by: Dimitrios Skarlatos
Signed-off-by: Dimitrios Skarlatos
Signed-off-by: YiFei Zhu
Reviewed-by: Jann Horn
Signed-off-by: Kees Cook
Link: https://lore.kernel.org/r/10f91a367ec4fcdea7fc3f086de3f5f13a4a7436.1602431034.git.yifeifz2@illinois.edu
(cherry picked from commit f9d480b6ffbeb336bf7f6ce44825c00f61b3abae)A
Signed-off-by: Jeff Vander Stoep
Change-Id: I50b6682e17dc6e91b5e92017361200d722282825
Bug: 176068146 -
Export hrtimer_expire_entry/exit tracepoints, so that vendor modules
can register probes for these tracepoints.Bug: 175936268
Change-Id: I739f369d3b56e09f8e9061fefdf25830e37e987e
Signed-off-by: Changki Kim -
Export workqueue_execute_start/end tracepoints, so that vendor modules
can register probes for these tracepoints.Bug: 175936268
Change-Id: Ib4c8f39ff8305a1d52fbca9d06b5e792396a3a2d
Signed-off-by: Changki Kim -
Export irq_handle_exit tracepoint, so that vendor modules
can register probes for this tracepoint.Bug: 175936268
Change-Id: I8e1eaffb7dd2f257e9c09412aad54ecca62bf019
Signed-off-by: Changki Kim -
Add a restricted vendor hook to check whether a set of tasks can
move to other cgorup.Bug: 175808144
Signed-off-by: Choonghoon Park
Change-Id: If7bac83e0d2d1069b1436331989c3926645eab19
21 Dec, 2020
15 commits
-
Changes in 5.10.2
ptrace: Prevent kernel-infoleak in ptrace_get_syscall_info()
ktest.pl: If size of log is too big to email, email error message
ktest.pl: Fix the logic for truncating the size of the log file for email
USB: legotower: fix logical error in recent commit
USB: dummy-hcd: Fix uninitialized array use in init()
USB: add RESET_RESUME quirk for Snapscan 1212
ALSA: usb-audio: Fix potential out-of-bounds shift
ALSA: usb-audio: Fix control 'access overflow' errors from chmap
xhci: Give USB2 ports time to enter U3 in bus suspend
usb: xhci: Set quirk for XHCI_SG_TRB_CACHE_SIZE_QUIRK
xhci-pci: Allow host runtime PM as default for Intel Alpine Ridge LP
xhci-pci: Allow host runtime PM as default for Intel Maple Ridge xHCI
USB: UAS: introduce a quirk to set no_write_same
USB: sisusbvga: Make console support depend on BROKEN
ALSA: pcm: oss: Fix potential out-of-bounds shift
serial: 8250_omap: Avoid FIFO corruption caused by MDR1 access
Linux 5.10.2Signed-off-by: Greg Kroah-Hartman
Change-Id: I0dfd41a3ba5b102699ef78641fbe48ed16957a0f -
Tested-by: Jeffrin Jose T
Tested-by: Guenter Roeck
Tested-by: Linux Kernel Functional Testing
Tested-by: Jon Hunter
Link: https://lore.kernel.org/r/20201219125339.066340030@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman -
commit d96f04d347e4011977abdbb4da5d8f303ebd26f8 upstream.
It has been observed that once per 300-1300 port openings the first
transmitted byte is being corrupted on AM3352 ("v" written to FIFO appeared
as "e" on the wire). It only happened if single byte has been transmitted
right after port open, which means, DMA is not used for this transfer and
the corruption never happened afterwards.Therefore I've carefully re-read the MDR1 errata (link below), which says
"when accessing the MDR1 registers that causes a dummy under-run condition
that will freeze the UART in IrDA transmission. In UART mode, this may
corrupt the transferred data". Strictly speaking,
omap_8250_mdr1_errataset() performs a read access and if the value is the
same as should be written, exits without errata-recommended FIFO reset.A brief check of the serial_omap_mdr1_errataset() from the competing
omap-serial driver showed it has no read access of MDR1. After removing the
read access from omap_8250_mdr1_errataset() the data corruption never
happened any more.Link: https://www.ti.com/lit/er/sprz360i/sprz360i.pdf
Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver")
Cc: stable@vger.kernel.org
Signed-off-by: Alexander Sverdlin
Link: https://lore.kernel.org/r/20201210055257.1053028-1-alexander.sverdlin@gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit 175b8d89fe292796811fdee87fa39799a5b6b87a upstream.
syzbot spotted a potential out-of-bounds shift in the PCM OSS layer
where it calculates the buffer size with the arbitrary shift value
given via an ioctl.Add a range check for avoiding the undefined behavior.
As the value can be treated by a signed integer, the max shift should
be 30.Reported-by: syzbot+df7dc146ebdd6435eea3@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20201209084552.17109-2-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 862ee699fefe1e6d6f2c1518395f0b999b8beb15 upstream.
The console part of sisusbvga is broken vs. printk(). It uses in_atomic()
to detect contexts in which it cannot sleep despite the big fat comment in
preempt.h which says: Do not use in_atomic() in driver code.in_atomic() does not work on kernels with CONFIG_PREEMPT_COUNT=n which
means that spin/rw_lock held regions are not detected by it.There is no way to make this work by handing context information through to
the driver and this only can be solved once the core printk infrastructure
supports sleepable console drivers.Make it depend on BROKEN for now.
Fixes: 1bbb4f2035d9 ("[PATCH] USB: sisusb[vga] update")
Signed-off-by: Thomas Gleixner
Cc: Thomas Winischhofer
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201019101109.603244207@linutronix.de
Signed-off-by: Greg Kroah-Hartman -
commit 8010622c86ca5bb44bc98492f5968726fc7c7a21 upstream.
UAS does not share the pessimistic assumption storage is making that
devices cannot deal with WRITE_SAME. A few devices supported by UAS,
are reported to not deal well with WRITE_SAME. Those need a quirk.Add it to the device that needs it.
Reported-by: David C. Partridge
Signed-off-by: Oliver Neukum
Cc: stable
Link: https://lore.kernel.org/r/20201209152639.9195-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman -
commit 5a8e3229ac27956bdcc25b2709e5d196d109a27a upstream.
Intel Maple Ridge is successor of Titan Ridge Thunderbolt controller. As
Titan Ridge this one also includes xHCI host controller. In order to
safe energy we should put it to low power state by default when idle.
For this reason allow host runtime PM for Maple Ridge.Signed-off-by: Mika Westerberg
Signed-off-by: Mathias Nyman
Link: https://lore.kernel.org/r/20201208092912.1773650-5-mathias.nyman@linux.intel.com
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
commit c4d1ca05b8e68a4b5a3c4455cb6ec25b3df6d9dd upstream.
The xHCI controller on Alpine Ridge LP keeps the whole Thunderbolt
controller awake if the host controller is not allowed to sleep.
This is the case even if no USB devices are connected to the host.Add the Intel Alpine Ridge LP product-id to the list of product-ids
for which we allow runtime PM by default.Fixes: 2815ef7fe4d4 ("xhci-pci: allow host runtime PM as default for Intel Alpine and Titan Ridge")
Cc:
Reviewed-by: Mika Westerberg
Signed-off-by: Hans de Goede
Signed-off-by: Mathias Nyman
Link: https://lore.kernel.org/r/20201208092912.1773650-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
commit bac1ec551434697ca3c5bb5d258811ba5446866a upstream.
This commit uses the private data passed by parent device
to set the quirk for Synopsys xHC. This patch fixes the
SNPS xHC hang issue when the data is scattered across
small buffers which does not make atleast MPS size for
given TRB cache size of SNPS xHC.Signed-off-by: Tejas Joglekar
Signed-off-by: Mathias Nyman
Link: https://lore.kernel.org/r/20201208092912.1773650-2-mathias.nyman@linux.intel.com
Cc: stable
Signed-off-by: Greg Kroah-Hartman -
commit c1373f10479b624fb6dba0805d673e860f1b421d upstream.
If a USB2 device wakeup is not enabled/supported the link state may
still be in U0 in xhci_bus_suspend(), where it's then manually put
to suspended U3 state.Just as with selective suspend the device needs time to enter U3
suspend before continuing with further suspend operations
(e.g. system suspend), otherwise we may enter system suspend with link
state in U0.[commit message rewording -Mathias]
Cc:
Signed-off-by: Li Jun
Signed-off-by: Mathias Nyman
Link: https://lore.kernel.org/r/20201208092912.1773650-6-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman -
commit c6dde8ffd071aea9d1ce64279178e470977b235c upstream.
The current channel-map control implementation in USB-audio driver may
lead to an error message like
"control 3:0:0:Playback Channel Map:0: access overflow"
when CONFIG_SND_CTL_VALIDATION is set. It's because the chmap get
callback clears the whole array no matter which count is set, and
rather the false-positive detection.This patch fixes the problem by clearing only the needed array range
at usb_chmap_ctl_get().Cc:
Link: https://lore.kernel.org/r/20201211130048.6358-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 43d5ca88dfcd35e43010fdd818e067aa9a55f5ba upstream.
syzbot spotted a potential out-of-bounds shift in the USB-audio format
parser that receives the arbitrary shift value from the USB
descriptor.Add a range check for avoiding the undefined behavior.
Reported-by: syzbot+df7dc146ebdd6435eea3@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20201209084552.17109-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 08a02f954b0def3ada8ed6d4b2c7bcb67e885e9c upstream.
I got reports that some models of this old scanner need
this when using runtime PM.Signed-off-by: Oliver Neukum
Cc: stable
Link: https://lore.kernel.org/r/20201207130323.23857-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman -
commit e90cfa813da7a527785033a0b247594c2de93dd8 upstream.
This error path
err_add_pdata:
for (i = 0; i < mod_data.num; i++)
kfree(dum[i]);can be triggered when not all dum's elements are initialized.
Fix this by initializing all dum's elements to NULL.
Acked-by: Alan Stern
Cc: stable
Signed-off-by: Bui Quang Minh
Link: https://lore.kernel.org/r/1607063090-3426-1-git-send-email-minhquangbui99@gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit b175d273d4e4100b66e68f0675fef7a3c07a7957 upstream.
Commit d9f0d82f06c6 ("USB: legousbtower: use usb_control_msg_recv()")
contained an elementary logical error. The check of the return code
from the new usb_control_msg_recv() function was inverted.Reported-and-tested-by: syzbot+9be25235b7a69b24d117@syzkaller.appspotmail.com
Signed-off-by: Alan Stern
Link: https://lore.kernel.org/r/20201208163042.GD1298255@rowland.harvard.edu
Fixes: d9f0d82f06c6 ("USB: legousbtower: use usb_control_msg_recv()")
Cc: stable
Signed-off-by: Greg Kroah-Hartman
