Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 5月, 2023 34 次提交
  3. 22 5月, 2023 6 次提交
    • J
      bpf: support BPF_PROG_QUERY for progs attached to sockmap · 05038388
      由 JofDiamonds 提交于 
      mainline inclusion
from mainline-v6.4-rc3
commit 748cd572
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I776SR
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=748cd5729ac7421091316e32dcdffb0578563880

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

Right now there is no way to query whether BPF programs are
attached to a sockmap or not.

we can use the standard interface in libbpf to query, such as:
bpf_prog_query(mapFd, BPF_SK_SKB_STREAM_PARSER, 0, NULL, ...);
the mapFd is the fd of sockmap.
Signed-off-by: NDi Zhu <zhudi2@huawei.com>
Acked-by: NYonghong Song <yhs@fb.com>
Reviewed-by: NJakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/r/20220119014005.1209-1-zhudi2@huawei.comSigned-off-by: NAlexei Starovoitov <ast@kernel.org>
Conflicts:
	net/core/sock_map.c
	include/linux/bpf.h
Signed-off-by: NJofDiamonds <kwb0523@163.com>
Reviewed-by: Nwuchangye <wuchangye@huawei.com>
      05038388
    • O
      !780 Backport 5.10.152 LTS · a74e16ec
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @sanglipeng 
 
Backport 5.10.152 LTS patches from upstream.

Conflicts:

Already merged(6):
392536023da1 block: wbt: Remove unnecessary invoking of wbt_update_limits in wbt_init
910ba49b3345 blk-wbt: call rq_qos_add() after wb_normal is initialized 
51b96ecaedc0 arm64: errata: Remove AES hwcap for COMPAT tasks  
7aa3d623c11b net: sched: fix race condition in qdisc_graft()  
f687e2111b6f fcntl: fix potential deadlocks for &fown_struct.lock 
  (merged mainline commit f671a691 fcntl: fix potential deadlocks for &fown_struct.lock)
31b1570677e8 blk-wbt: fix that 'rwb->wc' is always set to 1 in wbt_init() 

Context conflict(3):
dea47fefa6aa perf pmu: Validate raw event with sysfs exported format bits
b1efc196446a fcntl: make F_GETOWN(EX) return 0 on dead owner task

Rejected(1):
a6e770733dc4 arm64: topology: move store_cpu_topology() to shared code

Total patches: 72 - 6 -1 = 65 
 
Link:https://gitee.com/openeuler/kernel/pulls/780 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
      a74e16ec
    • P
      netfilter: nf_tables: deactivate anonymous set from preparation phase · dcb69fcc
      由 Pablo Neira Ayuso 提交于 
      stable inclusion
from stable-v5.10.180
commit e044a24447189419c3a7ccc5fa6da7516036dc55
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I71F49
CVE: CVE-2023-32233

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

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

commit c1592a89 upstream.

Toggle deleted anonymous sets as inactive in the next generation, so
users cannot perform any update on it. Clear the generation bitmask
in case the transaction is aborted.

The following KASAN splat shows a set element deletion for a bound
anonymous set that has been already removed in the same transaction.

[   64.921510] ==================================================================
[   64.923123] BUG: KASAN: wild-memory-access in nf_tables_commit+0xa24/0x1490 [nf_tables]
[   64.924745] Write of size 8 at addr dead000000000122 by task test/890
[   64.927903] CPU: 3 PID: 890 Comm: test Not tainted 6.3.0+ #253
[   64.931120] Call Trace:
[   64.932699]  <TASK>
[   64.934292]  dump_stack_lvl+0x33/0x50
[   64.935908]  ? nf_tables_commit+0xa24/0x1490 [nf_tables]
[   64.937551]  kasan_report+0xda/0x120
[   64.939186]  ? nf_tables_commit+0xa24/0x1490 [nf_tables]
[   64.940814]  nf_tables_commit+0xa24/0x1490 [nf_tables]
[   64.942452]  ? __kasan_slab_alloc+0x2d/0x60
[   64.944070]  ? nf_tables_setelem_notify+0x190/0x190 [nf_tables]
[   64.945710]  ? kasan_set_track+0x21/0x30
[   64.947323]  nfnetlink_rcv_batch+0x709/0xd90 [nfnetlink]
[   64.948898]  ? nfnetlink_rcv_msg+0x480/0x480 [nfnetlink]
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      dcb69fcc
    • D
      xfs: verify buffer contents when we skip log replay · d38a530e
      由 Darrick J. Wong 提交于 
      mainline inclusion
from mainline-v6.3-rc6
commit 22ed903e
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6X4UN
CVE: CVE-2023-2124

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=22ed903eee23a5b174e240f1cdfa9acf393a5210

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

syzbot detected a crash during log recovery:

XFS (loop0): Mounting V5 Filesystem bfdc47fc-10d8-4eed-a562-11a831b3f791
XFS (loop0): Torn write (CRC failure) detected at log block 0x180. Truncating head block from 0x200.
XFS (loop0): Starting recovery (logdev: internal)
==================================================================
BUG: KASAN: slab-out-of-bounds in xfs_btree_lookup_get_block+0x15c/0x6d0 fs/xfs/libxfs/xfs_btree.c:1813
Read of size 8 at addr ffff88807e89f258 by task syz-executor132/5074

CPU: 0 PID: 5074 Comm: syz-executor132 Not tainted 6.2.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106
 print_address_description+0x74/0x340 mm/kasan/report.c:306
 print_report+0x107/0x1f0 mm/kasan/report.c:417
 kasan_report+0xcd/0x100 mm/kasan/report.c:517
 xfs_btree_lookup_get_block+0x15c/0x6d0 fs/xfs/libxfs/xfs_btree.c:1813
 xfs_btree_lookup+0x346/0x12c0 fs/xfs/libxfs/xfs_btree.c:1913
 xfs_btree_simple_query_range+0xde/0x6a0 fs/xfs/libxfs/xfs_btree.c:4713
 xfs_btree_query_range+0x2db/0x380 fs/xfs/libxfs/xfs_btree.c:4953
 xfs_refcount_recover_cow_leftovers+0x2d1/0xa60 fs/xfs/libxfs/xfs_refcount.c:1946
 xfs_reflink_recover_cow+0xab/0x1b0 fs/xfs/xfs_reflink.c:930
 xlog_recover_finish+0x824/0x920 fs/xfs/xfs_log_recover.c:3493
 xfs_log_mount_finish+0x1ec/0x3d0 fs/xfs/xfs_log.c:829
 xfs_mountfs+0x146a/0x1ef0 fs/xfs/xfs_mount.c:933
 xfs_fs_fill_super+0xf95/0x11f0 fs/xfs/xfs_super.c:1666
 get_tree_bdev+0x400/0x620 fs/super.c:1282
 vfs_get_tree+0x88/0x270 fs/super.c:1489
 do_new_mount+0x289/0xad0 fs/namespace.c:3145
 do_mount fs/namespace.c:3488 [inline]
 __do_sys_mount fs/namespace.c:3697 [inline]
 __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f89fa3f4aca
Code: 83 c4 08 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fffd5fb5ef8 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00646975756f6e2c RCX: 00007f89fa3f4aca
RDX: 0000000020000100 RSI: 0000000020009640 RDI: 00007fffd5fb5f10
RBP: 00007fffd5fb5f10 R08: 00007fffd5fb5f50 R09: 000000000000970d
R10: 0000000000200800 R11: 0000000000000206 R12: 0000000000000004
R13: 0000555556c6b2c0 R14: 0000000000200800 R15: 00007fffd5fb5f50
 </TASK>

The fuzzed image contains an AGF with an obviously garbage
agf_refcount_level value of 32, and a dirty log with a buffer log item
for that AGF.  The ondisk AGF has a higher LSN than the recovered log
item.  xlog_recover_buf_commit_pass2 reads the buffer, compares the
LSNs, and decides to skip replay because the ondisk buffer appears to be
newer.

Unfortunately, the ondisk buffer is corrupt, but recovery just read the
buffer with no buffer ops specified:

	error = xfs_buf_read(mp->m_ddev_targp, buf_f->blf_blkno,
			buf_f->blf_len, buf_flags, &bp, NULL);

Skipping the buffer leaves its contents in memory unverified.  This sets
us up for a kernel crash because xfs_refcount_recover_cow_leftovers
reads the buffer (which is still around in XBF_DONE state, so no read
verification) and creates a refcountbt cursor of height 32.  This is
impossible so we run off the end of the cursor object and crash.

Fix this by invoking the verifier on all skipped buffers and aborting
log recovery if the ondisk buffer is corrupt.  It might be smarter to
force replay the log item atop the buffer and then see if it'll pass the
write verifier (like ext4 does) but for now let's go with the
conservative option where we stop immediately.

Link: https://syzkaller.appspot.com/bug?extid=7e9494b8b399902e994eSigned-off-by: NDarrick J. Wong <djwong@kernel.org>
Reviewed-by: NDave Chinner <dchinner@redhat.com>
Signed-off-by: NDave Chinner <david@fromorbit.com>
Signed-off-by: NLong Li <leo.lilong@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      d38a530e
    • Z
      iommu/arm-smmu-v3: Fix ECMDQs is not initialized correctly · 2dd184bf
      由 Zhen Lei 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6WAZX

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

When the number of cores is greater than the number of ECMDQs, the number
of ECMDQs occupied by each NUMA node is less than the number of cores of
the node. Therefore, the first smmu->nr_ecmdq cores do not cover all
ECMDQs.

For example:
 ---------------------------------------
|       Node0       |       Node1       |
|---------------------------------------|
|   0   1   2   3   |   4   5   6   7   |  CPU ID
|---------------------------------------|
|      0      1     |      2      3     |  ECMDQ ID
 ---------------------------------------

Fixes: 3965519b ("iommu/arm-smmu-v3: Add support for less than one ECMDQ per core")
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      2dd184bf
    • O
      !791 crypto: hisilicon/qm - support dumping stop queue status · 81da3d0b
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @xiao_jiang_shui 
 
Add debugfs 'dev_state' to query the status of the stop queue.
And the root user can set 'dev_timeout', if task flow fails to be
stopped, the driver waits dev_timeout * 20ms before releasing the queue.

关联issue：https://gitee.com/openeuler/kernel/issues/I76TVJ 
 
Link:https://gitee.com/openeuler/kernel/pulls/791 

Reviewed-by: Yang Shen <shenyang39@huawei.com> 
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com>
      81da3d0b