提交 · 2eea7319abf9aa9804e2eb03446fb190ee19cbb8 · openeuler / Kernel

14 1月, 2022 40 次提交

cgroup: Use open-time cgroup namespace for process migration perm checks · 2eea7319

由 Tejun Heo 提交于 1月 14, 2022

mainline inclusion
from mainline
commit e5745764
bugzilla: 186050 https://gitee.com/openeuler/kernel/issues/I4DDEL
CVE: CVE-2021-4197

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e57457641613fef0d147ede8bd6a3047df588b95

--------------------------------

cgroup process migration permission checks are performed at write time as
whether a given operation is allowed or not is dependent on the content of
the write - the PID. This currently uses current's cgroup namespace which is
a potential security weakness as it may allow scenarios where a less
privileged process tricks a more privileged one into writing into a fd that
it created.

This patch makes cgroup remember the cgroup namespace at the time of open
and uses it for migration permission checks instad of current's. Note that
this only applies to cgroup2 as cgroup1 doesn't have namespace support.

This also fixes a use-after-free bug on cgroupns reported in

 https://lore.kernel.org/r/00000000000048c15c05d0083397@google.com

Note that backporting this fix also requires the preceding patch.
Reported-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Suggested-by: NLinus Torvalds <torvalds@linuxfoundation.org>
Cc: Michal Koutný <mkoutny@suse.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Reviewed-by: NMichal Koutný <mkoutny@suse.com>
Reported-by: syzbot+50f5cf33a284ce738b62@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/00000000000048c15c05d0083397@google.com
Fixes: 5136f636 ("cgroup: implement "nsdelegate" mount option")
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NLu Jialin <lujialin4@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

2eea7319

cgroup: Allocate cgroup_file_ctx for kernfs_open_file->priv · 885c3688

由 Tejun Heo 提交于 1月 14, 2022

mainline inclusion
from mainline
commit 0d2b5955
bugzilla: 186050 https://gitee.com/openeuler/kernel/issues/I4DDEL
CVE: CVE-2021-4197

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0d2b5955b36250a9428c832664f2079cbf723bec

--------------------------------

of->priv is currently used by each interface file implementation to store
private information. This patch collects the current two private data usages
into struct cgroup_file_ctx which is allocated and freed by the common path.
This allows generic private data which applies to multiple files, which will
be used to in the following patch.

Note that cgroup_procs iterator is now embedded as procs.iter in the new
cgroup_file_ctx so that it doesn't need to be allocated and freed
separately.

v2: union dropped from cgroup_file_ctx and the procs iterator is embedded in
    cgroup_file_ctx as suggested by Linus.

v3: Michal pointed out that cgroup1's procs pidlist uses of->priv too.
    Converted. Didn't change to embedded allocation as cgroup1 pidlists get
    stored for caching.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: NMichal Koutný <mkoutny@suse.com>
Conflict:
	kernel/cgroup/cgroup.c
Signed-off-by: NLu Jialin <lujialin4@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

885c3688

cgroup: Use open-time credentials for process migraton perm checks · 0cf64d4c

由 Tejun Heo 提交于 1月 14, 2022

mainline inclusion
from mainline
commit 1756d799
bugzilla: 186050 https://gitee.com/openeuler/kernel/issues/I4DDEL
CVE: CVE-2021-4197

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1756d7994ad85c2479af6ae5a9750b92324685af

--------------------------------

cgroup process migration permission checks are performed at write time as
whether a given operation is allowed or not is dependent on the content of
the write - the PID. This currently uses current's credentials which is a
potential security weakness as it may allow scenarios where a less
privileged process tricks a more privileged one into writing into a fd that
it created.

This patch makes both cgroup2 and cgroup1 process migration interfaces to
use the credentials saved at the time of open (file->f_cred) instead of
current's.
Reported-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Suggested-by: NLinus Torvalds <torvalds@linuxfoundation.org>
Fixes: 187fe840 ("cgroup: require write perm on common ancestor when moving processes on the default hierarchy")
Reviewed-by: NMichal Koutný <mkoutny@suse.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Conflict:
	kernel/cgroup/cgroup-v1.c
Signed-off-by: NLu Jialin <lujialin4@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

0cf64d4c

cgroup/cgroup.c: replace 'of->kn->priv' with of_cft() · 1cc3e33b

由 liulangrenaaa 提交于 1月 14, 2022

mainline inclusion
from mainline-v5.11-rc2
commit 5a7b5f32
bugzilla: 186050 https://gitee.com/openeuler/kernel/issues/I4DDEL
CVE: CVE-2021-4197

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5a7b5f32c5aa628841502d19a813c633ff6ecbe4

--------------------------------

we have supplied the inline function: of_cft() in cgroup.h.

So replace the direct use 'of->kn->priv' with inline func
of_cft(), which is more readable.
Signed-off-by: Hui Su <sh_def@163.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NLu Jialin <lujialin4@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

1cc3e33b

cgroup: cgroup.{procs,threads} factor out common parts · 7d43c940

由 Michal Koutný 提交于 1月 14, 2022

mainline inclusion
from mainline-v5.12-rc1
commit da70862e
bugzilla: 186050 https://gitee.com/openeuler/kernel/issues/I4DDEL
CVE: CVE-2021-4197

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=da70862efe0065bada33d67a903270cdbbaf07d9

--------------------------------

The functions cgroup_threads_write and cgroup_procs_write are almost
identical. In order to reduce duplication, factor out the common code in
similar fashion we already do for other threadgroup/task functions. No
functional changes are intended.
Suggested-by: NHao Lee <haolee.swjtu@gmail.com>
Signed-off-by: NMichal Koutný <mkoutny@suse.com>
Reviewed-by: NDaniel Jordan <daniel.m.jordan@oracle.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NLu Jialin <lujialin4@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

7d43c940

netfilter: selftest: conntrack_vrf.sh: fix file permission · 72170121

由 Greg Kroah-Hartman 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.86
commit 32414491834c80ab39519467deb3f8d1e4f5bade
bugzilla: 186045 https://gitee.com/openeuler/kernel/issues/I4QVPD

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=32414491834c80ab39519467deb3f8d1e4f5bade

--------------------------------

When backporting 33b8aad2 ("selftests: netfilter: add a
vrf+conntrack testcase") to this stable branch, the executable bits were
not properly set on the
tools/testing/selftests/netfilter/conntrack_vrf.sh file due to quilt not
honoring them.

Fix this up manually by setting the correct mode.
Reported-by: N"Rantala, Tommi T. (Nokia - FI/Espoo)" <tommi.t.rantala@nokia.com>
Link: https://lore.kernel.org/r/234d7a6a81664610fdf21ac72730f8bd10d3f46f.camel@nokia.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

72170121

Documentation/Kbuild: Remove references to gcc-plugin.sh · fa370854

由 Robert Karszniewicz 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 47301c06f602f75fd7ba8a239a7de4b3b17aaa0d
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=47301c06f602f75fd7ba8a239a7de4b3b17aaa0d

--------------------------------

commit 1cabe74f upstream.

gcc-plugin.sh has been removed in commit
1e860048 ("gcc-plugins: simplify GCC plugin-dev capability test").
Signed-off-by: NRobert Karszniewicz <r.karszniewicz@phytec.de>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

fa370854

MAINTAINERS: adjust GCC PLUGINS after gcc-plugin.sh removal · 9792e450

由 Lukas Bulwahn 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit af5ba49cf7052aaa0b2c7d71f9cd85ef85a4cbfe
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=af5ba49cf7052aaa0b2c7d71f9cd85ef85a4cbfe

--------------------------------

commit 5136bb8c upstream.

Commit 1e860048 ("gcc-plugins: simplify GCC plugin-dev capability test")
removed ./scripts/gcc-plugin.sh, but missed to adjust MAINTAINERS.

Hence, ./scripts/get_maintainers.pl --self-test=patterns warns:

  warning: no file matches    F:    scripts/gcc-plugin.sh

Adjust entries in GGC PLUGINS section after this file removal.
Signed-off-by: NLukas Bulwahn <lukas.bulwahn@gmail.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

9792e450

doc: gcc-plugins: update gcc-plugins.rst · 773da24f

由 Masahiro Yamada 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit ad13421fd2cd49d68f422b4243958b3f05d562d2
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ad13421fd2cd49d68f422b4243958b3f05d562d2

--------------------------------

commit 9b616434 upstream.

This document was written a long time ago. Update it.

[1] Drop the version information

The range of the supported GCC versions are always changing. The
current minimal GCC version is 4.9, and commit 1e860048
("gcc-plugins: simplify GCC plugin-dev capability test") removed the
old code accordingly.

We do not need to mention specific version ranges like "all gcc versions
from 4.5 to 6.0" since we forget to update the documentation when we
raise the minimal compiler version.

[2] Drop the C compiler statements

Since commit 77342a02 ("gcc-plugins: drop support for GCC <= 4.7")
the GCC plugin infrastructure only supports g++.

[3] Drop supported architectures

As of v5.11-rc4, the infrastructure supports more architectures;
arm, arm64, mips, powerpc, riscv, s390, um, and x86. (just grep
"select HAVE_GCC_PLUGINS") Again, we miss to update this document when a
new architecture is supported. Let's just say "only some architectures".

[4] Update the apt-get example

We are now discussing to bump the minimal version to GCC 5. The GCC 4.9
support will be removed sooner or later. Change the package example to
gcc-10-plugin-dev while we are here.

[5] Update the build target

Since commit ce2fd53a ("kbuild: descend into scripts/gcc-plugins/
via scripts/Makefile"), "make gcc-plugins" is not supported.
"make scripts" builds all the enabled plugins, including some other
tools.

[6] Update the steps for adding a new plugin

At first, all CONFIG options for GCC plugins were located in arch/Kconfig.
After commit 45332b1b ("gcc-plugins: split out Kconfig entries to
scripts/gcc-plugins/Kconfig"), scripts/gcc-plugins/Kconfig became the
central place to collect plugin CONFIG options. In my understanding,
this requirement no longer exists because commit 9f671e58 ("security:
Create "kernel hardening" config area") moved some of plugin CONFIG
options to another file. Find an appropriate place to add the new CONFIG.

The sub-directory support was never used by anyone, and removed by
commit c17d6179 ("gcc-plugins: remove unused GCC_PLUGIN_SUBDIR").

Remove the useless $(src)/ prefix.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

773da24f

kbuild: simplify GCC_PLUGINS enablement in dummy-tools/gcc · 8bf441a4

由 Masahiro Yamada 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 9fc17c3af56cd0a3e501bf11e68650265096f1a2
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9fc17c3af56cd0a3e501bf11e68650265096f1a2

--------------------------------

commit f4c3b83b upstream.

With commit 1e860048 ("gcc-plugins: simplify GCC plugin-dev
capability test") applied, this hunk can be way simplified because
now scripts/gcc-plugins/Kconfig only checks plugin-version.h
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

8bf441a4

bpf: Add selftests to cover packet access corner cases · 1b5b4747

由 Maxim Mikityanskiy 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit d428e5477493946b77d1071e84b1475241974930
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d428e5477493946b77d1071e84b1475241974930

--------------------------------

commit b560b21f upstream.

This commit adds BPF verifier selftests that cover all corner cases by
packet boundary checks. Specifically, 8-byte packet reads are tested at
the beginning of data and at the beginning of data_meta, using all kinds
of boundary checks (all comparison operators: <, >, <=, >=; both
permutations of operands: data + length compared to end, end compared to
data + length). For each case there are three tests:

1. Length is just enough for an 8-byte read. Length is either 7 or 8,
   depending on the comparison.

2. Length is increased by 1 - should still pass the verifier. These
   cases are useful, because they failed before commit 2fa7d94a
   ("bpf: Fix the off-by-two error in range markings").

3. Length is decreased by 1 - should be rejected by the verifier.

Some existing tests are just renamed to avoid duplication.
Signed-off-by: NMaxim Mikityanskiy <maximmi@nvidia.com>
Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20211207081521.41923-1-maximmi@nvidia.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

1b5b4747

misc: fastrpc: fix improper packet size calculation · 244e01e3

由 Jeya R 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 0ec0eda3f3c3483872157a7780cebdf9bf3a11c4
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0ec0eda3f3c3483872157a7780cebdf9bf3a11c4

--------------------------------

commit 3a1bf591 upstream.

The buffer list is sorted and this is not being considered while
calculating packet size. This would lead to improper copy length
calculation for non-dmaheap buffers which would eventually cause
sending improper buffers to DSP.

Fixes: c68cfb71 ("misc: fastrpc: Add support for context Invoke method")
Reviewed-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NJeya R <jeyr@codeaurora.org>
Link: https://lore.kernel.org/r/1637771481-4299-1-git-send-email-jeyr@codeaurora.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

244e01e3

irqchip: nvic: Fix offset for Interrupt Priority Offsets · b36b881e

由 Vladimir Murzin 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 261d45a4c254ed75b6afdd65a5b1940199c911fb
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=261d45a4c254ed75b6afdd65a5b1940199c911fb

--------------------------------

commit c5e0cbe2 upstream.

According to ARM(v7M) ARM Interrupt Priority Offsets located at
0xE000E400-0xE000E5EC, while 0xE000E300-0xE000E33C covers read-only
Interrupt Active Bit Registers

Fixes: 292ec080 ("irqchip: Add support for ARMv7-M NVIC")
Signed-off-by: NVladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211201110259.84857-1-vladimir.murzin@arm.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b36b881e

irqchip/irq-gic-v3-its.c: Force synchronisation when issuing INVALL · aa66cec4

由 Wudi Wang 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit cd946f0ebe787068fd8070e06249706b29e86923
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cd946f0ebe787068fd8070e06249706b29e86923

--------------------------------

commit b383a42c upstream.

INVALL CMD specifies that the ITS must ensure any caching associated with
the interrupt collection defined by ICID is consistent with the LPI
configuration tables held in memory for all Redistributors. SYNC is
required to ensure that INVALL is executed.

Currently, LPI configuration data may be inconsistent with that in the
memory within a short period of time after the INVALL command is executed.
Signed-off-by: NWudi Wang <wangwudi@hisilicon.com>
Signed-off-by: NShaokun Zhang <zhangshaokun@hisilicon.com>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Fixes: cc2d3216 ("irqchip: GICv3: ITS command queue")
Link: https://lore.kernel.org/r/20211208015429.5007-1-zhangshaokun@hisilicon.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

aa66cec4

irqchip/armada-370-xp: Fix support for Multi-MSI interrupts · bd554bf9

由 Pali Rohár 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit e1c6611f822e6f55069005bdf4b431ebafcd85fb
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e1c6611f822e6f55069005bdf4b431ebafcd85fb

--------------------------------

commit d0a55350 upstream.

irq-armada-370-xp driver already sets MSI_FLAG_MULTI_PCI_MSI flag into
msi_domain_info structure. But allocated interrupt numbers for Multi-MSI
needs to be properly aligned otherwise devices send MSI interrupt with
wrong number.

Fix this issue by using function bitmap_find_free_region() instead of
bitmap_find_next_zero_area() to allocate aligned interrupt numbers.
Signed-off-by: NPali Rohár <pali@kernel.org>
Fixes: a71b9412 ("irqchip/armada-370-xp: Allow allocation of multiple MSIs")
Cc: stable@vger.kernel.org
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211125130057.26705-2-pali@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

bd554bf9

irqchip/armada-370-xp: Fix return value of armada_370_xp_msi_alloc() · a07c1e53

由 Pali Rohár 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 8f3ed9deaaac4044d89ae62756f2c3c79985b631
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8f3ed9deaaac4044d89ae62756f2c3c79985b631

--------------------------------

commit ce20eff5 upstream.

IRQ domain alloc function should return zero on success. Non-zero value
indicates failure.
Signed-off-by: NPali Rohár <pali@kernel.org>
Fixes: fcc392d5 ("irqchip/armada-370-xp: Use the generic MSI infrastructure")
Cc: stable@vger.kernel.org
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211125130057.26705-1-pali@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

a07c1e53

irqchip/aspeed-scu: Replace update_bits with write_bits. · 21b57408

由 Billy Tsai 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit d530e9943d643da34df4ab64698896f1e25ff38b
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d530e9943d643da34df4ab64698896f1e25ff38b

--------------------------------

commit 89583896 upstream.

The interrupt status bits are cleared by writing 1, we should force a
write to clear the interrupt without checking if the value has changed.

Fixes: 04f60590 ("irqchip: Add Aspeed SCU interrupt controller")
Signed-off-by: NBilly Tsai <billy_tsai@aspeedtech.com>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20211124094348.11621-1-billy_tsai@aspeedtech.com
Cc: stable@vger.kernel.org
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

21b57408

csky: fix typo of fpu config macro · 8b2dca7f

由 Kelly Devilliv 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 014c2fa5dc498acacb165c69ae1bb9f298e66e80
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=014c2fa5dc498acacb165c69ae1bb9f298e66e80

--------------------------------

commit a0793fda upstream.

Fix typo which will cause fpe and privilege exception error.
Signed-off-by: NKelly Devilliv <kelly.devilliv@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGuo Ren <guoren@linux.alibaba.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

8b2dca7f

iio: accel: kxcjk-1013: Fix possible memory leak in probe and remove · 05ed3bb4

由 Yang Yingliang 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit ee86d0bad80bdcd11a87e188a596727f41b62320
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ee86d0bad80bdcd11a87e188a596727f41b62320

--------------------------------

commit 70c9774e upstream.

When ACPI type is ACPI_SMO8500, the data->dready_trig will not be set, the
memory allocated by iio_triggered_buffer_setup() will not be freed, and cause
memory leak as follows:

unreferenced object 0xffff888009551400 (size 512):
  comm "i2c-SMO8500-125", pid 911, jiffies 4294911787 (age 83.852s)
  hex dump (first 32 bytes):
    02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 20 e2 e5 c0 ff ff ff ff  ........ .......
  backtrace:
    [<0000000041ce75ee>] kmem_cache_alloc_trace+0x16d/0x360
    [<000000000aeb17b0>] iio_kfifo_allocate+0x41/0x130 [kfifo_buf]
    [<000000004b40c1f5>] iio_triggered_buffer_setup_ext+0x2c/0x210 [industrialio_triggered_buffer]
    [<000000004375b15f>] kxcjk1013_probe+0x10c3/0x1d81 [kxcjk_1013]

Fix it by remove data->dready_trig condition in probe and remove.
Reported-by: NHulk Robot <hulkci@huawei.com>
Fixes: a25691c1 ("iio: accel: kxcjk1013: allow using an external trigger")
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Cc: <Stable@vger.kernel.org>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20211025124159.2700301-1-yangyingliang@huawei.comSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

05ed3bb4

iio: ad7768-1: Call iio_trigger_notify_done() on error · 2602ba15

由 Lars-Peter Clausen 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit c10c53419d8d723aa575f1ebbf5ce492b15e31fc
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c10c53419d8d723aa575f1ebbf5ce492b15e31fc

--------------------------------

commit 66611464 upstream.

IIO trigger handlers must call iio_trigger_notify_done() when done. This
must be done even when an error occurred. Otherwise the trigger will be
seen as busy indefinitely and the trigger handler will never be called
again.

The ad7768-1 driver neglects to call iio_trigger_notify_done() when there
is an error reading the converter data. Fix this by making sure that
iio_trigger_notify_done() is included in the error exit path.

Fixes: a5f8c7da ("iio: adc: Add AD7768-1 ADC basic support")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211101144055.13858-2-lars@metafoo.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

2602ba15

iio: adc: axp20x_adc: fix charging current reporting on AXP22x · 2665be3b

由 Evgeny Boger 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 0f86c9e818e74397de23eca01afe812a94d5deb7
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=0f86c9e818e74397de23eca01afe812a94d5deb7

--------------------------------

commit 92beafb7 upstream.

Both the charging and discharging currents on AXP22x are stored as
12-bit integers, in accordance with the datasheet.
It's also confirmed by vendor BSP (axp20x_adc.c:axp22_icharge_to_mA).

The scale factor of 0.5 is never mentioned in datasheet, nor in the
vendor source code. I think it was here to compensate for
erroneous addition bit in register width.

Tested on custom A40i+AXP221s board with external ammeter as
a reference.

Fixes: 0e34d5de ("iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs")
Signed-off-by: NEvgeny Boger <boger@wirenboard.com>
Acked-by: NChen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20211116213746.264378-1-boger@wirenboard.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

2665be3b

iio: adc: stm32: fix a current leak by resetting pcsel before disabling vdda · 682c3fd8

由 Fabrice Gasnier 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit af7fbb8c0b5438494ef5f6474011aebbb42ee00c
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=af7fbb8c0b5438494ef5f6474011aebbb42ee00c

--------------------------------

commit f711f28e upstream.

Some I/Os are connected to ADC input channels, when the corresponding bit
in PCSEL register are set on STM32H7 and STM32MP15. This is done in the
prepare routine of stm32-adc driver.
There are constraints here, as PCSEL shouldn't be set when VDDA supply
is disabled. Enabling/disabling of VDDA supply in done via stm32-adc-core
runtime PM routines (before/after ADC is enabled/disabled).

Currently, PCSEL remains set when disabling ADC. Later on, PM runtime
can disable the VDDA supply. This creates some conditions on I/Os that
can start to leak current.
So PCSEL needs to be cleared when disabling the ADC.

Fixes: 95e339b6 ("iio: adc: stm32: add support for STM32H7")
Signed-off-by: NFabrice Gasnier <fabrice.gasnier@foss.st.com>
Reviewed-by: NOlivier Moysan <olivier.moysan@foss.st.com>
Link: https://lore.kernel.org/r/1634905169-23762-1-git-send-email-fabrice.gasnier@foss.st.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

682c3fd8

iio: at91-sama5d2: Fix incorrect sign extension · 3f57b62a

由 Gwendal Grignou 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit fff92f3712d771103ca967dc8cb1180e5a48078a
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fff92f3712d771103ca967dc8cb1180e5a48078a

--------------------------------

commit 652e7df4 upstream.

Use scan_type when processing raw data which also fixes that the sign
extension was from the wrong bit.

Use channel definition as root of trust and replace constant
when reading elements directly using the raw sysfs attributes.

Fixes: 6794e23f ("iio: adc: at91-sama5d2_adc: add support for oversampling resolution")
Signed-off-by: NGwendal Grignou <gwendal@chromium.org>
Reviewed-by: NEugen Hristev <eugen.hristev@microchip.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20211104082413.3681212-9-gwendal@chromium.orgSigned-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

3f57b62a

iio: dln2: Check return value of devm_iio_trigger_register() · c321aacb

由 Lars-Peter Clausen 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit a2545b147d232122b5b9164dc23f277662f8fc71
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a2545b147d232122b5b9164dc23f277662f8fc71

--------------------------------

commit 90751fb9 upstream.

Registering a trigger can fail and the return value of
devm_iio_trigger_register() must be checked. Otherwise undefined behavior
can occur when the trigger is used.

Fixes: 7c0299e8 ("iio: adc: Add support for DLN2 ADC")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211101133043.6974-1-lars@metafoo.de
Cc: <stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c321aacb

iio: dln2-adc: Fix lockdep complaint · 13e748e7

由 Noralf Trønnes 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 69ae78c1abe7a968743996f86d6581d278c16c85
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=69ae78c1abe7a968743996f86d6581d278c16c85

--------------------------------

commit 59f92868 upstream.

When reading the voltage:

$ cat /sys/bus/iio/devices/iio\:device0/in_voltage0_raw

Lockdep complains:

[  153.910616] ======================================================
[  153.916918] WARNING: possible circular locking dependency detected
[  153.923221] 5.14.0+ #5 Not tainted
[  153.926692] ------------------------------------------------------
[  153.932992] cat/717 is trying to acquire lock:
[  153.937525] c2585358 (&indio_dev->mlock){+.+.}-{3:3}, at: iio_device_claim_direct_mode+0x28/0x44
[  153.946541]
               but task is already holding lock:
[  153.952487] c2585860 (&dln2->mutex){+.+.}-{3:3}, at: dln2_adc_read_raw+0x94/0x2bc [dln2_adc]
[  153.961152]
               which lock already depends on the new lock.

Fix this by not calling into the iio core underneath the dln2->mutex lock.

Fixes: 7c0299e8 ("iio: adc: Add support for DLN2 ADC")
Cc: Jack Andersen <jackoalan@gmail.com>
Signed-off-by: NNoralf Trønnes <noralf@tronnes.org>
Link: https://lore.kernel.org/r/20211018113731.25723-1-noralf@tronnes.org
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

13e748e7

iio: itg3200: Call iio_trigger_notify_done() on error · 45faa670

由 Lars-Peter Clausen 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 416383999c66e5171c4ae3e434289fd62fc1d4d9
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=416383999c66e5171c4ae3e434289fd62fc1d4d9

--------------------------------

commit 67fe2958 upstream.

IIO trigger handlers must call iio_trigger_notify_done() when done. This
must be done even when an error occurred. Otherwise the trigger will be
seen as busy indefinitely and the trigger handler will never be called
again.

The itg3200 driver neglects to call iio_trigger_notify_done() when there is
an error reading the gyro data. Fix this by making sure that
iio_trigger_notify_done() is included in the error exit path.

Fixes: 9dbf091d ("iio: gyro: Add itg3200")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211101144055.13858-1-lars@metafoo.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

45faa670

iio: kxsd9: Don't return error code in trigger handler · 7a9bd3a9

由 Lars-Peter Clausen 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit bc4d8367ed0d1478bfb56bcc387f7e1c82c3a003
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bc4d8367ed0d1478bfb56bcc387f7e1c82c3a003

--------------------------------

commit 45febe0d upstream.

IIO trigger handlers need to return one of the irqreturn_t values.
Returning an error code is not supported.

The kxsd9 interrupt handler returns an error code if reading the data
registers fails. In addition when exiting due to an error the trigger
handler does not call `iio_trigger_notify_done()`. Which when not done
keeps the triggered disabled forever.

Modify the code so that the function returns a valid irqreturn_t value as
well as calling `iio_trigger_notify_done()` on all exit paths.

Since we can't return the error code make sure to at least log it as part
of the error message.

Fixes: 0427a106 ("iio: accel: kxsd9: Add triggered buffer handling")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211024171251.22896-2-lars@metafoo.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

7a9bd3a9

iio: ltr501: Don't return error code in trigger handler · 2327f78b

由 Lars-Peter Clausen 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 28ea539a311e39dc07db9579cec5d10b84a5491b
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=28ea539a311e39dc07db9579cec5d10b84a5491b

--------------------------------

commit ef9d67fa upstream.

IIO trigger handlers need to return one of the irqreturn_t values.
Returning an error code is not supported.

The ltr501 interrupt handler gets this right for most error paths, but
there is one case where it returns the error code.

In addition for this particular case the trigger handler does not call
`iio_trigger_notify_done()`. Which when not done keeps the triggered
disabled forever.

Modify the code so that the function returns a valid irqreturn_t value as
well as calling `iio_trigger_notify_done()` on all exit paths.

Fixes: 2690be90 ("iio: Add Lite-On ltr501 ambient light / proximity sensor driver")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211024171251.22896-1-lars@metafoo.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

2327f78b

iio: mma8452: Fix trigger reference couting · 2d95e4c4

由 Lars-Peter Clausen 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit db12d95085367de8b0223929d1332731024441f1
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=db12d95085367de8b0223929d1332731024441f1

--------------------------------

commit cd008223 upstream.

The mma8452 driver directly assigns a trigger to the struct iio_dev. The
IIO core when done using this trigger will call `iio_trigger_put()` to drop
the reference count by 1.

Without the matching `iio_trigger_get()` in the driver the reference count
can reach 0 too early, the trigger gets freed while still in use and a
use-after-free occurs.

Fix this by getting a reference to the trigger before assigning it to the
IIO device.

Fixes: ae6d9ce0 ("iio: mma8452: Add support for interrupt driven triggers.")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211024092700.6844-1-lars@metafoo.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

2d95e4c4

iio: stk3310: Don't return error code in interrupt handler · bc9e9f5e

由 Lars-Peter Clausen 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 4e785291108450d462fd6989cd5090f1bb8f81b7
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4e785291108450d462fd6989cd5090f1bb8f81b7

--------------------------------

commit 8e1eeca5 upstream.

Interrupt handlers must return one of the irqreturn_t values. Returning a
error code is not supported.

The stk3310 event interrupt handler returns an error code when reading the
flags register fails.

Fix the implementation to always return an irqreturn_t value.

Fixes: 3dd477ac ("iio: light: Add threshold interrupt support for STK3310")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211024171251.22896-3-lars@metafoo.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

bc9e9f5e

iio: trigger: stm32-timer: fix MODULE_ALIAS · c4df8a13

由 Alyssa Ross 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 5c4a0f307f2bd64b63f2316ab386f7a58d1a3deb
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5c4a0f307f2bd64b63f2316ab386f7a58d1a3deb

--------------------------------

commit 893621e0 upstream.

modprobe can't handle spaces in aliases.

Fixes: 93fbe91b ("iio: Add STM32 timer trigger driver")
Signed-off-by: NAlyssa Ross <hi@alyssa.is>
Link: https://lore.kernel.org/r/20211125182850.2645424-1-hi@alyssa.is
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c4df8a13

iio: trigger: Fix reference counting · 5b1dca8f

由 Lars-Peter Clausen 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 5de9c5b13062e626c9f989d531f433a28d8c66b4
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5de9c5b13062e626c9f989d531f433a28d8c66b4

--------------------------------

commit a827a498 upstream.

In viio_trigger_alloc() device_initialize() is used to set the initial
reference count of the trigger to 1. Then another get_device() is called on
trigger. This sets the reference count to 2 before the trigger is returned.

iio_trigger_free(), which is the matching API to viio_trigger_alloc(),
calls put_device() which decreases the reference count by 1. But the second
reference count acquired in viio_trigger_alloc() is never dropped.

As a result the iio_trigger_release() function is never called and the
memory associated with the trigger is never freed.

Since there is no reason for the trigger to start its lifetime with two
reference counts just remove the extra get_device() in
viio_trigger_alloc().

Fixes: 5f9c035c ("staging:iio:triggers. Add a reference get to the core for triggers.")
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NNuno Sá <nuno.sa@analog.com>
Link: https://lore.kernel.org/r/20211024092700.6844-2-lars@metafoo.de
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

5b1dca8f

iio: gyro: adxrs290: fix data signedness · a1703322

由 Kister Genesis Jimenez 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit cbc04c0c9a67b8039a3b14d63c67067e6224dc76
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cbc04c0c9a67b8039a3b14d63c67067e6224dc76

--------------------------------

commit fde272e7 upstream.

Properly sign-extend the rate and temperature data.

Fixes: 2c8920ff ("iio: gyro: Add driver support for ADXRS290")
Signed-off-by: NKister Genesis Jimenez <kister.jimenez@analog.com>
Signed-off-by: NNuno Sá <nuno.sa@analog.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Link: https://lore.kernel.org/r/20211115104147.18669-1-nuno.sa@analog.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

a1703322

xhci: avoid race between disable slot command and host runtime suspend · 58aa642c

由 Mathias Nyman 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit fee8be5bde562d4f5f9a100ca80c6d7072ed34c8
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fee8be5bde562d4f5f9a100ca80c6d7072ed34c8

--------------------------------

commit 7faac195 upstream.

Make xhci_disable_slot() synchronous, thus ensuring it, and
xhci_free_dev() calling it return after xHC controller completes
the disable slot command.

Otherwise the roothub and xHC host may runtime suspend, and clear the
command ring while the disable slot command is being processed.

This causes a command completion mismatch as the completion event can't
be mapped to the correct command.
Command ring gets out of sync and commands time out.
Driver finally assumes host is unresponsive and bails out.

usb 2-4: USB disconnect, device number 10
xhci_hcd 0000:00:0d.0: ERROR mismatched command completion event
...
xhci_hcd 0000:00:0d.0: xHCI host controller not responding, assume dead
xhci_hcd 0000:00:0d.0: HC died; cleaning up

Cc: <stable@vger.kernel.org>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211210141735.1384209-3-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

58aa642c

usb: core: config: using bit mask instead of individual bits · c8395ab6

由 Pavel Hofman 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 1b43c9b65f6b506759092e542eb9fe055d7c9a08
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1b43c9b65f6b506759092e542eb9fe055d7c9a08

--------------------------------

commit ca573739 upstream.

Using standard USB_EP_MAXP_MULT_MASK instead of individual bits for
extracting multiple-transactions bits from wMaxPacketSize value.
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NPavel Hofman <pavel.hofman@ivitera.com>
Link: https://lore.kernel.org/r/20211210085219.16796-2-pavel.hofman@ivitera.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c8395ab6

xhci: Remove CONFIG_USB_DEFAULT_PERSIST to prevent xHCI from runtime suspending · 540d953d

由 Kai-Heng Feng 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 74b6a6a239aa1a823f8bc00eb80851df9777ae29
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=74b6a6a239aa1a823f8bc00eb80851df9777ae29

--------------------------------

commit 811ae813 upstream.

When the xHCI is quirked with XHCI_RESET_ON_RESUME, runtime resume
routine also resets the controller.

This is bad for USB drivers without reset_resume callback, because
there's no subsequent call of usb_dev_complete() ->
usb_resume_complete() to force rebinding the driver to the device. For
instance, btusb device stops working after xHCI controller is runtime
resumed, if the controlled is quirked with XHCI_RESET_ON_RESUME.

So always take XHCI_RESET_ON_RESUME into account to solve the issue.

Cc: <stable@vger.kernel.org>
Signed-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20211210141735.1384209-2-mathias.nyman@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

540d953d

usb: core: config: fix validation of wMaxPacketValue entries · d6cd620c

由 Pavel Hofman 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit ef284f086dd07451bef391fc0a7f47a24b3b9e02
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ef284f086dd07451bef391fc0a7f47a24b3b9e02

--------------------------------

commit 1a3910c8 upstream.

The checks performed by commit aed9d65a ("USB: validate
wMaxPacketValue entries in endpoint descriptors") require that initial
value of the maxp variable contains both maximum packet size bits
(10..0) and multiple-transactions bits (12..11). However, the existing
code assings only the maximum packet size bits. This patch assigns all
bits of wMaxPacketSize to the variable.

Fixes: aed9d65a ("USB: validate wMaxPacketValue entries in endpoint descriptors")
Cc: stable <stable@vger.kernel.org>
Acked-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NPavel Hofman <pavel.hofman@ivitera.com>
Link: https://lore.kernel.org/r/20211210085219.16796-1-pavel.hofman@ivitera.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

d6cd620c

USB: gadget: zero allocate endpoint 0 buffers · bc369038

由 Greg Kroah-Hartman 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit e4de8ca013f06ad4a0bf40420a291c23990e4131
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e4de8ca013f06ad4a0bf40420a291c23990e4131

--------------------------------

commit 86ebbc11 upstream.

Under some conditions, USB gadget devices can show allocated buffer
contents to a host.  Fix this up by zero-allocating them so that any
extra data will all just be zeros.
Reported-by: NSzymon Heidrich <szymon.heidrich@gmail.com>
Tested-by: NSzymon Heidrich <szymon.heidrich@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

bc369038

selftests/fib_tests: Rework fib_rp_filter_test() · 0975d0a9

由 Peilin Ye 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 63fc70bffa16de431a51da7f530011de1b469780
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=63fc70bffa16de431a51da7f530011de1b469780

--------------------------------

commit f6071e5e upstream.

Currently rp_filter tests in fib_tests.sh:fib_rp_filter_test() are
failing.  ping sockets are bound to dummy1 using the "-I" option
(SO_BINDTODEVICE), but socket lookup is failing when receiving ping
replies, since the routing table thinks they belong to dummy0.

For example, suppose ping is using a SOCK_RAW socket for ICMP messages.
When receiving ping replies, in __raw_v4_lookup(), sk->sk_bound_dev_if
is 3 (dummy1), but dif (skb_rtable(skb)->rt_iif) says 2 (dummy0), so the
raw_sk_bound_dev_eq() check fails.  Similar things happen in
ping_lookup() for SOCK_DGRAM sockets.

These tests used to pass due to a bug [1] in iputils, where "ping -I"
actually did not bind ICMP message sockets to device.  The bug has been
fixed by iputils commit f455fee41c07 ("ping: also bind the ICMP socket
to the specific device") in 2016, which is why our rp_filter tests
started to fail.  See [2] .

Fixing the tests while keeping everything in one netns turns out to be
nontrivial.  Rework the tests and build the following topology:

 ┌─────────────────────────────┐    ┌─────────────────────────────┐
 │  network namespace 1 (ns1)  │    │  network namespace 2 (ns2)  │
 │                             │    │                             │
 │  ┌────┐     ┌─────┐         │    │  ┌─────┐            ┌────┐  │
 │  │ lo │<───>│veth1│<────────┼────┼─>│veth2│<──────────>│ lo │  │
 │  └────┘     ├─────┴──────┐  │    │  ├─────┴──────┐     └────┘  │
 │             │192.0.2.1/24│  │    │  │192.0.2.1/24│             │
 │             └────────────┘  │    │  └────────────┘             │
 └─────────────────────────────┘    └─────────────────────────────┘

Consider sending an ICMP_ECHO packet A in ns2.  Both source and
destination IP addresses are 192.0.2.1, and we use strict mode rp_filter
in both ns1 and ns2:

  1. A is routed to lo since its destination IP address is one of ns2's
     local addresses (veth2);
  2. A is redirected from lo's egress to veth2's egress using mirred;
  3. A arrives at veth1's ingress in ns1;
  4. A is redirected from veth1's ingress to lo's ingress, again, using
     mirred;
  5. In __fib_validate_source(), fib_info_nh_uses_dev() returns false,
     since A was received on lo, but reverse path lookup says veth1;
  6. However A is not dropped since we have relaxed this check for lo in
     commit 66f82095 ("fib: relax source validation check for loopback
     packets");

Making sure A is not dropped here in this corner case is the whole point
of having this test.

  7. As A reaches the ICMP layer, an ICMP_ECHOREPLY packet, B, is
     generated;
  8. Similarly, B is redirected from lo's egress to veth1's egress (in
     ns1), then redirected once again from veth2's ingress to lo's
     ingress (in ns2), using mirred.

Also test "ping 127.0.0.1" from ns2.  It does not trigger the relaxed
check in __fib_validate_source(), but just to make sure the topology
works with loopback addresses.

Tested with ping from iputils 20210722-41-gf9fb573:

$ ./fib_tests.sh -t rp_filter

IPv4 rp_filter tests
    TEST: rp_filter passes local packets		[ OK ]
    TEST: rp_filter passes loopback packets		[ OK ]

[1] https://github.com/iputils/iputils/issues/55
[2] https://github.com/iputils/iputils/commit/f455fee41c077d4b700a473b2f5b3487b8febc1dReported-by: NHangbin Liu <liuhangbin@gmail.com>
Fixes: adb701d6 ("selftests: add a test case for rp_filter")
Reviewed-by: NCong Wang <cong.wang@bytedance.com>
Signed-off-by: NPeilin Ye <peilin.ye@bytedance.com>
Acked-by: NDavid Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20211201004720.6357-1-yepeilin.cs@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

0975d0a9

net/qla3xxx: fix an error code in ql_adapter_up() · 986ee5dd

由 Dan Carpenter 提交于 1月 14, 2022

stable inclusion
from stable-v5.10.85
commit 126d1897cbff8f616eebcf69dae0ce6e0d25b1b0
bugzilla: 186032 https://gitee.com/openeuler/kernel/issues/I4QVI4

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=126d1897cbff8f616eebcf69dae0ce6e0d25b1b0

--------------------------------

commit d17b9737 upstream.

The ql_wait_for_drvr_lock() fails and returns false, then this
function should return an error code instead of returning success.

The other problem is that the success path prints an error message
netdev_err(ndev, "Releasing driver lock\n");  Delete that and
re-order the code a little to make it more clear.

Fixes: 5a4faa87 ("[PATCH] qla3xxx NIC driver")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211207082416.GA16110@kiliSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

986ee5dd

openeuler / Kernel 1 年多 前同步成功

openeuler / Kernel
1 年多前同步成功