提交 · e6e41c7fe1fc2fd4886f79d881a794fb84ee7277 · openeuler / Kernel

09 11月, 2021 7 次提交

drivers/perf: hisi: update the sccl_id/ccl_id for certain HiSilicon platform · e6e41c7f

由 Shaokun Zhang 提交于 11月 09, 2021

mainline inclusion
from mainline-v5.4-rc1
commit 8703317a
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4A1XO
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8703317ae576c9bf3e07e5b97275e3f957e8d74b

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

For some HiSilicon platform, the originally designed SCCL_ID and CCL_ID
are not satisfied with much rich topology when the MT is set, so we
extend the SCCL_ID to MPIDR[aff3] and CCL_ID to MPIDR[aff2]. Let's
update this for HiSilicon uncore PMU driver.

Cc: John Garry <john.garry@huawei.com>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: NShaokun Zhang <zhangshaokun@hisilicon.com>
Signed-off-by: NWill Deacon <will@kernel.org>
Signed-off-by: NQi Liu <liuqi115@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

e6e41c7f

perf/smmuv3: Validate groups for global filtering · ddc64804

由 Robin Murphy 提交于 11月 09, 2021

mainline inclusion
from mainline-v5.3-rc1
commit 3c934735
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4A1XO
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c9347351a6ea1234aa647b36f89052de050d2a2

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

With global filtering, it becomes possible for users to construct
self-contradictory groups with conflicting filters. Make sure we
cover that when initially validating events.
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NWill Deacon <will@kernel.org>
Signed-off-by: NQi Liu <liuqi115@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

ddc64804

perf/smmuv3: Validate group size · 60413b24

由 Robin Murphy 提交于 11月 09, 2021

mainline inclusion
from mainline-v5.3-rc1
commit 33e84ea4
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4A1XO
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=33e84ea4330da8a16bda8a871d0cd3c872bcd89f

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

Ensure that a group will actually fit into the available counters.
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NWill Deacon <will@kernel.org>
Signed-off-by: NQi Liu <liuqi115@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

60413b24

drivers/perf: arm_spe: Don't error on high-order pages for aux buf · 0a78fc27

由 Will Deacon 提交于 11月 09, 2021

mainline inclusion
from mainline-v5.1-rc3
commit 14ae42a6
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4A1XO
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=14ae42a6f0b13130a97d94d23481128961de5d38

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

Since commit 5768402f ("perf/ring_buffer: Use high order allocations
for AUX buffers optimistically"), the perf core tends to back aux buffer
allocations with high-order pages with the order encoded in the
PagePrivate data. The Arm SPE driver explicitly rejects such pages,
causing the perf tool to fail with:

  | failed to mmap with 12 (Cannot allocate memory)

In actual fact, we can simply treat these pages just like any other
since the perf core takes care to populate the page array appropriately.
In theory we could try to map with PMDs where possible, but for now,
let's just get things working again.

Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Fixes: 5768402f ("perf/ring_buffer: Use high order allocations for AUX buffers optimistically")
Reported-by: NHanjun Guo <guohanjun@huawei.com>
Tested-by: NHanjun Guo <guohanjun@huawei.com>
Tested-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NQi Liu <liuqi115@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

0a78fc27

drm/hisilicon: Features to support reading resolutions from EDID · 1e510d40

由 Tian Tao 提交于 11月 09, 2021

mainline inclusion
from mainline-v5.14.0-rc7
commit a0d078d0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I469VQ
CVE: NA

Refactoring hibmc_vdac_init, hibmc_connector_init method.

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

Use drm_get_edid to get the resolution, if that fails, set it to
a fixed resolution. Rewrite the desrtoy callback function to release
resources.
Signed-off-by: NTian Tao <tiantao6@hisilicon.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1600778670-60370-3-git-send-email-tiantao6@hisilicon.comSigned-off-by: Ngouhao <gouhao@uniontech.com>
Reviewed-by: Ntian tao <tiantao6@hisilicon.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

1e510d40

drm/hisilicon: Support i2c driver algorithms for bit-shift adapters · 61c106b4

由 Tian Tao 提交于 11月 09, 2021

mainline inclusion
from mainline-v5.14.0-rc7
commit 4eb4d99d
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I469VQ
CVE: NA

Remove #include <drm/drm_probe_helper.h> in hibmc_drm_i2c.c.

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

Adding driver implementation to support i2c driver algorithms for
bit-shift adapters, so hibmc will using the interface provided by
drm to read edid.
Signed-off-by: NTian Tao <tiantao6@hisilicon.com>
Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1600778670-60370-2-git-send-email-tiantao6@hisilicon.comSigned-off-by: Ngouhao <gouhao@uniontech.com>
Reviewed-by: Ntian tao <tiantao6@hisilicon.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

61c106b4

compiler.h: fix barrier_data() on clang · d2e4cce1

由 Arvind Sankar 提交于 11月 09, 2021

stable inclusion
from linux-4.19.164
commit b207caff4176e3a6ba273243da2db2e595e4aad2
CVE: CVE-2021-0938

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

commit 3347acc6 upstream.

Commit 815f0ddb ("include/linux/compiler*.h: make compiler-*.h
mutually exclusive") neglected to copy barrier_data() from
compiler-gcc.h into compiler-clang.h.

The definition in compiler-gcc.h was really to work around clang's more
aggressive optimization, so this broke barrier_data() on clang, and
consequently memzero_explicit() as well.

For example, this results in at least the memzero_explicit() call in
lib/crypto/sha256.c:sha256_transform() being optimized away by clang.

Fix this by moving the definition of barrier_data() into compiler.h.

Also move the gcc/clang definition of barrier() into compiler.h,
__memory_barrier() is icc-specific (and barrier() is already defined
using it in compiler-intel.h) and doesn't belong in compiler.h.

[rdunlap@infradead.org: fix ALPHA builds when SMP is not enabled]

Link: https://lkml.kernel.org/r/20201101231835.4589-1-rdunlap@infradead.org
Fixes: 815f0ddb ("include/linux/compiler*.h: make compiler-*.h mutually exclusive")
Signed-off-by: NArvind Sankar <nivedita@alum.mit.edu>
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Tested-by: NNick Desaulniers <ndesaulniers@google.com>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20201014212631.207844-1-nivedita@alum.mit.eduSigned-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
[nd: backport to account for missing
  commit e506ea45 ("compiler.h: Split {READ,WRITE}_ONCE definitions out into rwonce.h")
  commit d08b9f0c ("scs: Add support for Clang's Shadow Call Stack (SCS)")
  commit a3f8a30f ("Compiler Attributes: use feature checks instead of version checks")]
Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

d2e4cce1

08 11月, 2021 9 次提交

bonding: Fix a use-after-free problem when bond_sysfs_slave_add() failed · 6821c267

由 Huang Guobin 提交于 11月 08, 2021

mainline inclusion
from mainline-v5.15
commit b93c6a91
category: bugfix
bugzilla: 185687
CVE: NA

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

When I do fuzz test for bonding device interface, I got the following
use-after-free Calltrace:

==================================================================
BUG: KASAN: use-after-free in bond_enslave+0x1521/0x24f0
Read of size 8 at addr ffff88825bc11c00 by task ifenslave/7365

CPU: 5 PID: 7365 Comm: ifenslave Tainted: G            E     5.15.0-rc1+ #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014
Call Trace:
 dump_stack_lvl+0x6c/0x8b
 print_address_description.constprop.0+0x48/0x70
 kasan_report.cold+0x82/0xdb
 __asan_load8+0x69/0x90
 bond_enslave+0x1521/0x24f0
 bond_do_ioctl+0x3e0/0x450
 dev_ifsioc+0x2ba/0x970
 dev_ioctl+0x112/0x710
 sock_do_ioctl+0x118/0x1b0
 sock_ioctl+0x2e0/0x490
 __x64_sys_ioctl+0x118/0x150
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f19159cf577
Code: b3 66 90 48 8b 05 11 89 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 78
RSP: 002b:00007ffeb3083c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007ffeb3084bca RCX: 00007f19159cf577
RDX: 00007ffeb3083ce0 RSI: 0000000000008990 RDI: 0000000000000003
RBP: 00007ffeb3084bc4 R08: 0000000000000040 R09: 0000000000000000
R10: 00007ffeb3084bc0 R11: 0000000000000246 R12: 00007ffeb3083ce0
R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffeb3083cb0

Allocated by task 7365:
 kasan_save_stack+0x23/0x50
 __kasan_kmalloc+0x83/0xa0
 kmem_cache_alloc_trace+0x22e/0x470
 bond_enslave+0x2e1/0x24f0
 bond_do_ioctl+0x3e0/0x450
 dev_ifsioc+0x2ba/0x970
 dev_ioctl+0x112/0x710
 sock_do_ioctl+0x118/0x1b0
 sock_ioctl+0x2e0/0x490
 __x64_sys_ioctl+0x118/0x150
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Freed by task 7365:
 kasan_save_stack+0x23/0x50
 kasan_set_track+0x20/0x30
 kasan_set_free_info+0x24/0x40
 __kasan_slab_free+0xf2/0x130
 kfree+0xd1/0x5c0
 slave_kobj_release+0x61/0x90
 kobject_put+0x102/0x180
 bond_sysfs_slave_add+0x7a/0xa0
 bond_enslave+0x11b6/0x24f0
 bond_do_ioctl+0x3e0/0x450
 dev_ifsioc+0x2ba/0x970
 dev_ioctl+0x112/0x710
 sock_do_ioctl+0x118/0x1b0
 sock_ioctl+0x2e0/0x490
 __x64_sys_ioctl+0x118/0x150
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Last potentially related work creation:
 kasan_save_stack+0x23/0x50
 kasan_record_aux_stack+0xb7/0xd0
 insert_work+0x43/0x190
 __queue_work+0x2e3/0x970
 delayed_work_timer_fn+0x3e/0x50
 call_timer_fn+0x148/0x470
 run_timer_softirq+0x8a8/0xc50
 __do_softirq+0x107/0x55f

Second to last potentially related work creation:
 kasan_save_stack+0x23/0x50
 kasan_record_aux_stack+0xb7/0xd0
 insert_work+0x43/0x190
 __queue_work+0x2e3/0x970
 __queue_delayed_work+0x130/0x180
 queue_delayed_work_on+0xa7/0xb0
 bond_enslave+0xe25/0x24f0
 bond_do_ioctl+0x3e0/0x450
 dev_ifsioc+0x2ba/0x970
 dev_ioctl+0x112/0x710
 sock_do_ioctl+0x118/0x1b0
 sock_ioctl+0x2e0/0x490
 __x64_sys_ioctl+0x118/0x150
 do_syscall_64+0x35/0xb0
 entry_SYSCALL_64_after_hwframe+0x44/0xae

The buggy address belongs to the object at ffff88825bc11c00
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 0 bytes inside of
 1024-byte region [ffff88825bc11c00, ffff88825bc12000)
The buggy address belongs to the page:
page:ffffea00096f0400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x25bc10
head:ffffea00096f0400 order:3 compound_mapcount:0 compound_pincount:0
flags: 0x57ff00000010200(slab|head|node=1|zone=2|lastcpupid=0x7ff)
raw: 057ff00000010200 ffffea0009a71c08 ffff888240001968 ffff88810004dbc0
raw: 0000000000000000 00000000000a000a 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88825bc11b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88825bc11b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88825bc11c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                   ^
 ffff88825bc11c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88825bc11d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

Put new_slave in bond_sysfs_slave_add() will cause use-after-free problems
when new_slave is accessed in the subsequent error handling process. Since
new_slave will be put in the subsequent error handling process, remove the
unnecessary put to fix it.
In addition, when sysfs_create_file() fails, if some files have been crea-
ted successfully, we need to call sysfs_remove_file() to remove them.
Since there are sysfs_create_files() & sysfs_remove_files() can be used,
use these two functions instead.

Fixes: 7afcaec4 (bonding: use kobject_put instead of _del after kobject_add)
Signed-off-by: NHuang Guobin <huangguobin4@huawei.com>
Reviewed-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NHuang Guobin <huangguobin4@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

6821c267

ANDROID: staging: ion: move buffer kmap from begin/end_cpu_access() · 47e4d3c1

由 Hridya Valsaraju 提交于 11月 08, 2021

hulk inclusion
category: bugfix
bugzilla: NA
CVE: CVE-2021-0929

https://source.android.com/security/bulletin/2021-11-01
https://android-review.googlesource.com/c/kernel/common/+/1780045
---------------------------

Since dma_buf_begin/end_cpu_access() calls always used to bracket
dma_buf_kmap/kunmap calls, ION performed kmap/kunmap invocations for the
buffer during dma_buf_begin/end_cpu_access() calls and cached the
results with a kmap counter.
However, dma_buf_begin/end_cpu_access() invocations can be
triggered from the userspace using the DMA_BUF_IOC_SYNC ioctl as well.
This means that a mapping that was created by a device driver using by a
dma_buf_kmap() call or an ion_map_kernel() call could be unmapped
from userspace if a client accidentally(or maliciously) invoked
DMA_BUF_IOCTL_SYNC IOCTL with 'DMA_BUF_SYNC_END' argument since this
would inturn invoke dma_buf_end_cpu_access() which would then decrement
the kmap counter and invoke kunmap() when the counter gets to 0.

This patch moves the kmap/kunmap operations from the
begin/end_cpu_access() DMA-BUF ops to the map/unmap DMA-BUF ops to
prevent the issue.

Bug: 187527909
Change-Id: I00dc8eefefb1f3aab99e770f90d624011f7740f0
Signed-off-by: NHridya Valsaraju <hridya@google.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>

47e4d3c1

ath9k: Postpone key cache entry deletion for TXQ frames reference it · 87a9e0b9