Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 04 4月, 2023 5 次提交
  3. 03 4月, 2023 2 次提交
  5. 01 4月, 2023 1 次提交
  7. 31 3月, 2023 1 次提交
  9. 29 3月, 2023 31 次提交
    • O
      !529 Backport CVEs and bugfixes · 358a5fb9
      由 openeuler-ci-bot 提交于 
      Merge Pull Request from: @zhangjialin11 
 
Pull new CVEs:
CVE-2023-1281
CVE-2022-48423
CVE-2023-1249
CVE-2022-48425
CVE-2022-48424
CVE-2023-28327
CVE-2023-28466
CVE-2023-1380

block and md/raid6 bugfixes from Zhong Jinghua
fs bugfixes from Zhihao Cheng and Baokun Li
tty bugfix from Yi Yang
mm bugfixes from ZhangPeng and Ze Zuo
bpf bugfixes from Pu Lehui and Liu Jian
ima bugfix from GUO Zihua
softirq and arch bugfixes from Lin Yujun 
 
Link:https://gitee.com/openeuler/kernel/pulls/529 

Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>
      358a5fb9
    • M
      block: fix use-after-free of q->q_usage_counter · 3a651d39
      由 Ming Lei 提交于 
      mainline inclusion
from mainline-v6.2-rc1
commit d36a9ea5
category: bugfix
bugzilla: 187268, https://gitee.com/openeuler/kernel/issues/I5N162

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

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

For blk-mq, queue release handler is usually called after
blk_mq_freeze_queue_wait() returns. However, the
q_usage_counter->release() handler may not be run yet at that time, so
this can cause a use-after-free.

Fix the issue by moving percpu_ref_exit() into blk_free_queue_rcu().
Since ->release() is called with rcu read lock held, it is agreed that
the race should be covered in caller per discussion from the two links.
Reported-by: NZhang Wensheng <zhangwensheng@huaweicloud.com>
Reported-by: NZhong Jinghua <zhongjinghua@huawei.com>
Link: https://lore.kernel.org/linux-block/Y5prfOjyyjQKUrtH@T590/T/#u
Link: https://lore.kernel.org/lkml/Y4%2FmzMd4evRg9yDi@fedora/
Cc: Hillf Danton <hdanton@sina.com>
Cc: Yu Kuai <yukuai3@huawei.com>
Cc: Dennis Zhou <dennis@kernel.org>
Fixes: 2b0d3d3e ("percpu_ref: reduce memory footprint of percpu_ref in fast path")
Signed-off-by: NMing Lei <ming.lei@redhat.com>
Link: https://lore.kernel.org/r/20221215021629.74870-1-ming.lei@redhat.comSigned-off-by: NJens Axboe <axboe@kernel.dk>

conflicts:
 block/blk-sysfs.c
 block/blk-core.c
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      3a651d39
    • M
      block: move q_usage_counter release into blk_queue_release · cde762ef
      由 Ming Lei 提交于 
      mainline inclusion
from mainline-v5.18-rc1
commit ba3e8456
category: bugfix
bugzilla: 187268, https://gitee.com/openeuler/kernel/issues/I5N162

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

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

After blk_cleanup_queue() returns, disk may not be released yet, so
probably bio may still be submitted and ->q_usage_counter may be
touched, so far this way seems safe, but not good from API's viewpoint.

Move the release q_usage_counter into blk_queue_release().
Signed-off-by: NMing Lei <ming.lei@redhat.com>
Reviewed-by: NBart Van Assche <bvanassche@acm.org>
Signed-off-by: NChristoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20220308055200.735835-12-hch@lst.deSigned-off-by: NJens Axboe <axboe@kernel.dk>

conflicts:
 block/blk-core.c
 block/blk-sysfs.c
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      cde762ef
    • Z
      Revert "block: fix null-deref in percpu_ref_put" · 60469540
      由 Zhong Jinghua 提交于 
      hulk inclusion
category: bugfix
bugzilla: 187268, https://gitee.com/openeuler/kernel/issues/I5N162

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

This reverts commit 51e35e67.

There is a new fix for this problem in the mainline patch, so the patch
should return to the mainline solution.

mainline patch:
d36a9ea5 ("block: fix use-after-free of q->q_usage_counter")

Fixes: 51e35e67("block: fix null-deref in percpu_ref_put")
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      60469540
    • M
      mm: compaction: avoid possible NULL pointer dereference in kcompactd_cpu_online · 4928d2df
      由 Miaohe Lin 提交于 
      mainline inclusion
from mainline-v6.3-rc1
commit 3109de30
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6POXN
CVE: NA

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

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

It's possible that kcompactd_run could fail to run kcompactd for a hot
added node and leave pgdat->kcompactd as NULL.  So pgdat->kcompactd should
be checked here to avoid possible NULL pointer dereference.

Link: https://lkml.kernel.org/r/20220418141253.24298-10-linmiaohe@huawei.comSigned-off-by: NMiaohe Lin <linmiaohe@huawei.com>
Cc: Charan Teja Kalla <charante@codeaurora.org>
Cc: David Hildenbrand <david@redhat.com>
Cc: Pintu Kumar <pintu@codeaurora.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NZe Zuo <zuoze1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      4928d2df
    • Z
      md/raid6: Fix the problem of repeatedly applying for memory in raid5_read_one_chunk · 5c00a00f
      由 Zhong Jinghua 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6OSXU

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

commit "md/raid6: refactor raid5_read_one_chunk" incorrectly merged the
code.
Repeatedly applying for memory leads to memory leaks.

Fix it by removing redundant allocating memory code.

Fixes: c13c2cd2 ("md/raid6: refactor raid5_read_one_chunk")
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      5c00a00f
    • D
      xfs, iomap: limit individual ioend chain lengths in writeback · c5883137
      由 Dave Chinner 提交于 
      mainline inclusion
from mainline-v5.17-rc3
commit ebb7fb15
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4KIAO
CVE: NA

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

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

Trond Myklebust reported soft lockups in XFS IO completion such as
this:

 watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [kworker/12:1:3106]
 CPU: 12 PID: 3106 Comm: kworker/12:1 Not tainted 4.18.0-305.10.2.el8_4.x86_64 #1
 Workqueue: xfs-conv/md127 xfs_end_io [xfs]
 RIP: 0010:_raw_spin_unlock_irqrestore+0x11/0x20
 Call Trace:
  wake_up_page_bit+0x8a/0x110
  iomap_finish_ioend+0xd7/0x1c0
  iomap_finish_ioends+0x7f/0xb0
  xfs_end_ioend+0x6b/0x100 [xfs]
  xfs_end_io+0xb9/0xe0 [xfs]
  process_one_work+0x1a7/0x360
  worker_thread+0x1fa/0x390
  kthread+0x116/0x130
  ret_from_fork+0x35/0x40

Ioends are processed as an atomic completion unit when all the
chained bios in the ioend have completed their IO. Logically
contiguous ioends can also be merged and completed as a single,
larger unit.  Both of these things can be problematic as both the
bio chains per ioend and the size of the merged ioends processed as
a single completion are both unbound.

If we have a large sequential dirty region in the page cache,
write_cache_pages() will keep feeding us sequential pages and we
will keep mapping them into ioends and bios until we get a dirty
page at a non-sequential file offset. These large sequential runs
can will result in bio and ioend chaining to optimise the io
patterns. The pages iunder writeback are pinned within these chains
until the submission chaining is broken, allowing the entire chain
to be completed. This can result in huge chains being processed
in IO completion context.

We get deep bio chaining if we have large contiguous physical
extents. We will keep adding pages to the current bio until it is
full, then we'll chain a new bio to keep adding pages for writeback.
Hence we can build bio chains that map millions of pages and tens of
gigabytes of RAM if the page cache contains big enough contiguous
dirty file regions. This long bio chain pins those pages until the
final bio in the chain completes and the ioend can iterate all the
chained bios and complete them.

OTOH, if we have a physically fragmented file, we end up submitting
one ioend per physical fragment that each have a small bio or bio
chain attached to them. We do not chain these at IO submission time,
but instead we chain them at completion time based on file
offset via iomap_ioend_try_merge(). Hence we can end up with unbound
ioend chains being built via completion merging.

XFS can then do COW remapping or unwritten extent conversion on that
merged chain, which involves walking an extent fragment at a time
and running a transaction to modify the physical extent information.
IOWs, we merge all the discontiguous ioends together into a
contiguous file range, only to then process them individually as
discontiguous extents.

This extent manipulation is computationally expensive and can run in
a tight loop, so merging logically contiguous but physically
discontigous ioends gains us nothing except for hiding the fact the
fact we broke the ioends up into individual physical extents at
submission and then need to loop over those individual physical
extents at completion.

Hence we need to have mechanisms to limit ioend sizes and
to break up completion processing of large merged ioend chains:

1. bio chains per ioend need to be bound in length. Pure overwrites
go straight to iomap_finish_ioend() in softirq context with the
exact bio chain attached to the ioend by submission. Hence the only
way to prevent long holdoffs here is to bound ioend submission
sizes because we can't reschedule in softirq context.

2. iomap_finish_ioends() has to handle unbound merged ioend chains
correctly. This relies on any one call to iomap_finish_ioend() being
bound in runtime so that cond_resched() can be issued regularly as
the long ioend chain is processed. i.e. this relies on mechanism #1
to limit individual ioend sizes to work correctly.

3. filesystems have to loop over the merged ioends to process
physical extent manipulations. This means they can loop internally,
and so we break merging at physical extent boundaries so the
filesystem can easily insert reschedule points between individual
extent manipulations.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reported-and-tested-by: NTrond Myklebust <trondmy@hammerspace.com>
Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
Conflicts:
	include/linux/iomap.h
	fs/iomap/buffered-io.c
	fs/xfs/xfs_aops.c

	[ 6e552494 ("iomap: remove unused private field from ioend")
	  is not applied.
	  95c4cd05 ("iomap: Convert to_iomap_page to take a folio") is
	  not applied.
	  8ffd74e9 ("iomap: Convert bio completions to use folios") is
	  not applied.
	  044c6449 ("xfs: drop unused ioend private merge and
	  setfilesize code") is not applied. ]
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      c5883137
    • P
      net/sched: tcindex: search key must be 16 bits · 01359ed3
      由 Pedro Tammela 提交于 
      stable inclusion
from stable-v5.10.168
commit 4fe9950815e19051b7b8268b4d4c3ac286a741bf
category: bugfix
bugzilla: 188576, https://gitee.com/src-openeuler/kernel/issues/I6OP9S
CVE: CVE-2023-1281

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

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

[ Upstream commit 42018a32 ]

Syzkaller found an issue where a handle greater than 16 bits would trigger
a null-ptr-deref in the imperfect hash area update.

general protection fault, probably for non-canonical address
0xdffffc0000000015: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af]
CPU: 0 PID: 5070 Comm: syz-executor456 Not tainted
6.2.0-rc7-syzkaller-00112-gc68f345b #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/21/2023
RIP: 0010:tcindex_set_parms+0x1a6a/0x2990 net/sched/cls_tcindex.c:509
Code: 01 e9 e9 fe ff ff 4c 8b bd 28 fe ff ff e8 0e 57 7d f9 48 8d bb
a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c
02 00 0f 85 94 0c 00 00 48 8b 85 f8 fd ff ff 48 8b 9b a8 00
RSP: 0018:ffffc90003d3ef88 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000015 RSI: ffffffff8803a102 RDI: 00000000000000a8
RBP: ffffc90003d3f1d8 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: ffff88801e2b10a8
R13: dffffc0000000000 R14: 0000000000030000 R15: ffff888017b3be00
FS: 00005555569af300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000056041c6d2000 CR3: 000000002bfca000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
tcindex_change+0x1ea/0x320 net/sched/cls_tcindex.c:572
tc_new_tfilter+0x96e/0x2220 net/sched/cls_api.c:2155
rtnetlink_rcv_msg+0x959/0xca0 net/core/rtnetlink.c:6132
netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
netlink_sendmsg+0x91b/0xe10 net/netlink/af_netlink.c:1942
sock_sendmsg_nosec net/socket.c:714 [inline]
sock_sendmsg+0xd3/0x120 net/socket.c:734
____sys_sendmsg+0x334/0x8c0 net/socket.c:2476
___sys_sendmsg+0x110/0x1b0 net/socket.c:2530
__sys_sendmmsg+0x18f/0x460 net/socket.c:2616
__do_sys_sendmmsg net/socket.c:2645 [inline]
__se_sys_sendmmsg net/socket.c:2642 [inline]
__x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2642
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80

Fixes: ee059170 ("net/sched: tcindex: update imperfect hash filters respecting rcu")
Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: NPedro Tammela <pctammela@mojatatu.com>
Reported-by: Nsyzbot <syzkaller@googlegroups.com>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      01359ed3
    • P
      net/sched: tcindex: update imperfect hash filters respecting rcu · c5eaa264
      由 Pedro Tammela 提交于 
      stable inclusion
from stable-v5.10.168
commit eb8e9d8572d1d9df17272783ad8a84843ce559d4
category: bugfix
bugzilla: 188576, https://gitee.com/src-openeuler/kernel/issues/I6OP9S
CVE: CVE-2023-1281

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

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

commit ee059170 upstream.

The imperfect hash area can be updated while packets are traversing,
which will cause a use-after-free when 'tcf_exts_exec()' is called
with the destroyed tcf_ext.

CPU 0:               CPU 1:
tcindex_set_parms    tcindex_classify
tcindex_lookup
                     tcindex_lookup
tcf_exts_change
                     tcf_exts_exec [UAF]

Stop operating on the shared area directly, by using a local copy,
and update the filter with 'rcu_replace_pointer()'. Delete the old
filter version only after a rcu grace period elapsed.

Fixes: 9b0d4446 ("net: sched: avoid atomic swap in tcf_exts_change")
Reported-by: Nvalis <sec@valis.email>
Suggested-by: Nvalis <sec@valis.email>
Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: NPedro Tammela <pctammela@mojatatu.com>
Link: https://lore.kernel.org/r/20230209143739.279867-1-pctammela@mojatatu.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      c5eaa264
    • S
      tty: fix out-of-bounds access in tty_driver_lookup_tty() · 03106cb1
      由 Sven Schnelle 提交于 
      stable inclusion
from stable-v5.10.173
commit 84ea44dc3e4ecb2632586238014bf6722aa5843b
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6Q4F0
CVE: NA

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

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

[ Upstream commit db4df8e9 ]

When specifying an invalid console= device like console=tty3270,
tty_driver_lookup_tty() returns the tty struct without checking
whether index is a valid number.

To reproduce:

qemu-system-x86_64 -enable-kvm -nographic -serial mon:stdio \
-kernel ../linux-build-x86/arch/x86/boot/bzImage \
-append "console=ttyS0 console=tty3270"

This crashes with:

[    0.770599] BUG: kernel NULL pointer dereference, address: 00000000000000ef
[    0.771265] #PF: supervisor read access in kernel mode
[    0.771773] #PF: error_code(0x0000) - not-present page
[    0.772609] Oops: 0000 [#1] PREEMPT SMP PTI
[    0.774878] RIP: 0010:tty_open+0x268/0x6f0
[    0.784013]  chrdev_open+0xbd/0x230
[    0.784444]  ? cdev_device_add+0x80/0x80
[    0.784920]  do_dentry_open+0x1e0/0x410
[    0.785389]  path_openat+0xca9/0x1050
[    0.785813]  do_filp_open+0xaa/0x150
[    0.786240]  file_open_name+0x133/0x1b0
[    0.786746]  filp_open+0x27/0x50
[    0.787244]  console_on_rootfs+0x14/0x4d
[    0.787800]  kernel_init_freeable+0x1e4/0x20d
[    0.788383]  ? rest_init+0xc0/0xc0
[    0.788881]  kernel_init+0x11/0x120
[    0.789356]  ret_from_fork+0x22/0x30
Signed-off-by: NSven Schnelle <svens@linux.ibm.com>
Reviewed-by: NJiri Slaby <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20221209112737.3222509-2-svens@linux.ibm.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYi Yang <yiyang13@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Reviewed-by: NCai Xinchen <caixinchen1@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      03106cb1
    • E
      fs/ntfs3: Validate resident attribute name · af9e000b
      由 Edward Lo 提交于 
      mainline inclusion
from mainline-v6.2-rc1
commit 54e45702
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6OD4U
CVE: CVE-2022-48423

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

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

Though we already have some sanity checks while enumerating attributes,
resident attribute names aren't included. This patch checks the resident
attribute names are in the valid ranges.

[  259.209031] BUG: KASAN: slab-out-of-bounds in ni_create_attr_list+0x1e1/0x850
[  259.210770] Write of size 426 at addr ffff88800632f2b2 by task exp/255
[  259.211551]
[  259.212035] CPU: 0 PID: 255 Comm: exp Not tainted 6.0.0-rc6 #37
[  259.212955] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[  259.214387] Call Trace:
[  259.214640]  <TASK>
[  259.214895]  dump_stack_lvl+0x49/0x63
[  259.215284]  print_report.cold+0xf5/0x689
[  259.215565]  ? kasan_poison+0x3c/0x50
[  259.215778]  ? kasan_unpoison+0x28/0x60
[  259.215991]  ? ni_create_attr_list+0x1e1/0x850
[  259.216270]  kasan_report+0xa7/0x130
[  259.216481]  ? ni_create_attr_list+0x1e1/0x850
[  259.216719]  kasan_check_range+0x15a/0x1d0
[  259.216939]  memcpy+0x3c/0x70
[  259.217136]  ni_create_attr_list+0x1e1/0x850
[  259.217945]  ? __rcu_read_unlock+0x5b/0x280
[  259.218384]  ? ni_remove_attr+0x2e0/0x2e0
[  259.218712]  ? kernel_text_address+0xcf/0xe0
[  259.219064]  ? __kernel_text_address+0x12/0x40
[  259.219434]  ? arch_stack_walk+0x9e/0xf0
[  259.219668]  ? __this_cpu_preempt_check+0x13/0x20
[  259.219904]  ? sysvec_apic_timer_interrupt+0x57/0xc0
[  259.220140]  ? asm_sysvec_apic_timer_interrupt+0x1b/0x20
[  259.220561]  ni_ins_attr_ext+0x52c/0x5c0
[  259.220984]  ? ni_create_attr_list+0x850/0x850
[  259.221532]  ? run_deallocate+0x120/0x120
[  259.221972]  ? vfs_setxattr+0x128/0x300
[  259.222688]  ? setxattr+0x126/0x140
[  259.222921]  ? path_setxattr+0x164/0x180
[  259.223431]  ? __x64_sys_setxattr+0x6d/0x80
[  259.223828]  ? entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  259.224417]  ? mi_find_attr+0x3c/0xf0
[  259.224772]  ni_insert_attr+0x1ba/0x420
[  259.225216]  ? ni_ins_attr_ext+0x5c0/0x5c0
[  259.225504]  ? ntfs_read_ea+0x119/0x450
[  259.225775]  ni_insert_resident+0xc0/0x1c0
[  259.226316]  ? ni_insert_nonresident+0x400/0x400
[  259.227001]  ? __kasan_kmalloc+0x88/0xb0
[  259.227468]  ? __kmalloc+0x192/0x320
[  259.227773]  ntfs_set_ea+0x6bf/0xb30
[  259.228216]  ? ftrace_graph_ret_addr+0x2a/0xb0
[  259.228494]  ? entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  259.228838]  ? ntfs_read_ea+0x450/0x450
[  259.229098]  ? is_bpf_text_address+0x24/0x40
[  259.229418]  ? kernel_text_address+0xcf/0xe0
[  259.229681]  ? __kernel_text_address+0x12/0x40
[  259.229948]  ? unwind_get_return_address+0x3a/0x60
[  259.230271]  ? write_profile+0x270/0x270
[  259.230537]  ? arch_stack_walk+0x9e/0xf0
[  259.230836]  ntfs_setxattr+0x114/0x5c0
[  259.231099]  ? ntfs_set_acl_ex+0x2e0/0x2e0
[  259.231529]  ? evm_protected_xattr_common+0x6d/0x100
[  259.231817]  ? posix_xattr_acl+0x13/0x80
[  259.232073]  ? evm_protect_xattr+0x1f7/0x440
[  259.232351]  __vfs_setxattr+0xda/0x120
[  259.232635]  ? xattr_resolve_name+0x180/0x180
[  259.232912]  __vfs_setxattr_noperm+0x93/0x300
[  259.233219]  __vfs_setxattr_locked+0x141/0x160
[  259.233492]  ? kasan_poison+0x3c/0x50
[  259.233744]  vfs_setxattr+0x128/0x300
[  259.234002]  ? __vfs_setxattr_locked+0x160/0x160
[  259.234837]  do_setxattr+0xb8/0x170
[  259.235567]  ? vmemdup_user+0x53/0x90
[  259.236212]  setxattr+0x126/0x140
[  259.236491]  ? do_setxattr+0x170/0x170
[  259.236791]  ? debug_smp_processor_id+0x17/0x20
[  259.237232]  ? kasan_quarantine_put+0x57/0x180
[  259.237605]  ? putname+0x80/0xa0
[  259.237870]  ? __kasan_slab_free+0x11c/0x1b0
[  259.238234]  ? putname+0x80/0xa0
[  259.238500]  ? preempt_count_sub+0x18/0xc0
[  259.238775]  ? __mnt_want_write+0xaa/0x100
[  259.238990]  ? mnt_want_write+0x8b/0x150
[  259.239290]  path_setxattr+0x164/0x180
[  259.239605]  ? setxattr+0x140/0x140
[  259.239849]  ? debug_smp_processor_id+0x17/0x20
[  259.240174]  ? fpregs_assert_state_consistent+0x67/0x80
[  259.240411]  __x64_sys_setxattr+0x6d/0x80
[  259.240715]  do_syscall_64+0x3b/0x90
[  259.240934]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  259.241697] RIP: 0033:0x7fc6b26e4469
[  259.242647] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088
[  259.244512] RSP: 002b:00007ffc3c7841f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000bc
[  259.245086] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc6b26e4469
[  259.246025] RDX: 00007ffc3c784380 RSI: 00007ffc3c7842e0 RDI: 00007ffc3c784238
[  259.246961] RBP: 00007ffc3c788410 R08: 0000000000000001 R09: 00007ffc3c7884f8
[  259.247775] R10: 000000000000007f R11: 0000000000000217 R12: 00000000004004e0
[  259.248534] R13: 00007ffc3c7884f0 R14: 0000000000000000 R15: 0000000000000000
[  259.249368]  </TASK>
[  259.249644]
[  259.249888] Allocated by task 255:
[  259.250283]  kasan_save_stack+0x26/0x50
[  259.250957]  __kasan_kmalloc+0x88/0xb0
[  259.251826]  __kmalloc+0x192/0x320
[  259.252745]  ni_create_attr_list+0x11e/0x850
[  259.253298]  ni_ins_attr_ext+0x52c/0x5c0
[  259.253685]  ni_insert_attr+0x1ba/0x420
[  259.253974]  ni_insert_resident+0xc0/0x1c0
[  259.254311]  ntfs_set_ea+0x6bf/0xb30
[  259.254629]  ntfs_setxattr+0x114/0x5c0
[  259.254859]  __vfs_setxattr+0xda/0x120
[  259.255155]  __vfs_setxattr_noperm+0x93/0x300
[  259.255445]  __vfs_setxattr_locked+0x141/0x160
[  259.255862]  vfs_setxattr+0x128/0x300
[  259.256251]  do_setxattr+0xb8/0x170
[  259.256522]  setxattr+0x126/0x140
[  259.256911]  path_setxattr+0x164/0x180
[  259.257308]  __x64_sys_setxattr+0x6d/0x80
[  259.257637]  do_syscall_64+0x3b/0x90
[  259.257970]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  259.258550]
[  259.258772] The buggy address belongs to the object at ffff88800632f000
[  259.258772]  which belongs to the cache kmalloc-1k of size 1024
[  259.260190] The buggy address is located 690 bytes inside of
[  259.260190]  1024-byte region [ffff88800632f000, ffff88800632f400)
[  259.261412]
[  259.261743] The buggy address belongs to the physical page:
[  259.262354] page:0000000081e8cac9 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x632c
[  259.263722] head:0000000081e8cac9 order:2 compound_mapcount:0 compound_pincount:0
[  259.264284] flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
[  259.265312] raw: 000fffffc0010200 ffffea0000060d00 dead000000000004 ffff888001041dc0
[  259.265772] raw: 0000000000000000 0000000080080008 00000001ffffffff 0000000000000000
[  259.266305] page dumped because: kasan: bad access detected
[  259.266588]
[  259.266728] Memory state around the buggy address:
[  259.267225]  ffff88800632f300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  259.267841]  ffff88800632f380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  259.269111] >ffff88800632f400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  259.269626]                    ^
[  259.270162]  ffff88800632f480: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[  259.270810]  ffff88800632f500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
Signed-off-by: NEdward Lo <edward.lo@ambergroup.io>
Signed-off-by: NKonstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: NZhaoLong Wang <wangzhaolong1@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>
      af9e000b
    • G
      ima: Fix memory leakage in ima_store_template · 010e7840
      由 GUO Zihua 提交于 
      Offering: HULK
hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6P3K4
CVE: NA

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

There is a memory leakage in ima_store_template when ima_add_template_entry
returns a non-zero value and duplicated_entry was successfully
generated. Fix it by freeing duplicated_entry in that case.

Fixes: 31604143 ("ima: Add support for measurement with digest lists")
Signed-off-by: NGUO Zihua <guozihua@huawei.com>
Reviewed-by: Nyiyang <yiyang13@huawei.com>
Reviewed-by: NCai Xinchen <caixinchen1@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      010e7840
    • Z
      Revert "mm/vmalloc: huge vmalloc backing pages should be split rather than compound" · fd3548d8
      由 ZhangPeng 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6LD0S
CVE: NA

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

This reverts commit 49ed1f1e.

It will have a great impact on the product if we can't use vmalloc to
alloc high-order physical pages.
Signed-off-by: NZhangPeng <zhangpeng362@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      fd3548d8
    • L
      coredump: fix kabi broken in struct coredump_params · 2d14573e
      由 Li Huafei 提交于 
      Offering: HULK
hulk inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6KT9C
CVE: CVE-2023-1249

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

The coredump_params structure is only used as parameters for function
pointer members of some structures, such as linux_binfmt, spufs_calls,
etc., and the parameters are of pointer type, so adding members of
coredump_params will not affect the memory layout.

Also coredump_params is used to hold coredump parameters to be passed to
coredump functions of different types of binfmt, the driver will not use
the structure.
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      2d14573e
    • E
      coredump: Use the vma snapshot in fill_files_note · 5ba037e0
      由 Eric W. Biederman 提交于 
      stable inclusion
from stable-v5.10.110
commit 558564db44755dfb3e48b0d64de327d20981e950
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6KT9C
CVE: CVE-2023-1249

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

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

commit 390031c9 upstream.

Matthew Wilcox reported that there is a missing mmap_lock in
file_files_note that could possibly lead to a user after free.

Solve this by using the existing vma snapshot for consistency
and to avoid the need to take the mmap_lock anywhere in the
coredump code except for dump_vma_snapshot.

Update the dump_vma_snapshot to capture vm_pgoff and vm_file
that are neeeded by fill_files_note.

Add free_vma_snapshot to free the captured values of vm_file.
Reported-by: NMatthew Wilcox <willy@infradead.org>
Link: https://lkml.kernel.org/r/20220131153740.2396974-1-willy@infradead.org
Cc: stable@vger.kernel.org
Fixes: a07279c9 ("binfmt_elf, binfmt_elf_fdpic: use a VMA list snapshot")
Fixes: 2aa362c4 ("coredump: extend core dump note section to contain file names of mapped files")
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      5ba037e0
    • E
      coredump/elf: Pass coredump_params into fill_note_info · a682fb18
      由 Eric W. Biederman 提交于 
      stable inclusion
from stable-v5.10.110
commit b7933f145ad32bb5e084af55176ab6dcaa15a036
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6KT9C
CVE: CVE-2023-1249

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

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

commit 9ec7d323 upstream.

Instead of individually passing cprm->siginfo and cprm->regs
into fill_note_info pass all of struct coredump_params.

This is preparation to allow fill_files_note to use the existing
vma snapshot.
Reviewed-by: NJann Horn <jannh@google.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      a682fb18
    • E
      coredump: Remove the WARN_ON in dump_vma_snapshot · a6541c35
      由 Eric W. Biederman 提交于 
      stable inclusion
from stable-v5.10.110
commit b043ae637a83585b2a497c2eb7ee49446fc68e98
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6KT9C
CVE: CVE-2023-1249

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

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

commit 49c18663 upstream.

The condition is impossible and to the best of my knowledge has never
triggered.

We are in deep trouble if that conditions happens and we walk past
the end of our allocated array.

So delete the WARN_ON and the code that makes it look like the kernel
can handle the case of walking past the end of it's vma_meta array.
Reviewed-by: NJann Horn <jannh@google.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      a6541c35
    • E
      coredump: Snapshot the vmas in do_coredump · 0e07125c
      由 Eric W. Biederman 提交于 
      stable inclusion
from stable-v5.10.110
commit 936c8be4d1447f36ac4d2a464bd03a5cd659c42f
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6KT9C
CVE: CVE-2023-1249

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

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

commit 95c5436a upstream.

Move the call of dump_vma_snapshot and kvfree(vma_meta) out of the
individual coredump routines into do_coredump itself.  This makes
the code less error prone and easier to maintain.

Make the vma snapshot available to the coredump routines
in struct coredump_params.  This makes it easier to
change and update what is captures in the vma snapshot
and will be needed for fixing fill_file_notes.
Reviewed-by: NJann Horn <jannh@google.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      0e07125c
    • L
      mm/swapfile: add cond_resched() in get_swap_pages() · 010c4efc
      由 Longlong Xia 提交于 
      mainline inclusion
from mainline-v6.2-rc7
commit 7717fc1a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I645DG
CVE: NA

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

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

The softlockup still occurs in get_swap_pages() under memory pressure.  64
CPU cores, 64GB memory, and 28 zram devices, the disksize of each zram
device is 50MB with same priority as si.  Use the stress-ng tool to
increase memory pressure, causing the system to oom frequently.

The plist_for_each_entry_safe() loops in get_swap_pages() could reach tens
of thousands of times to find available space (extreme case:
cond_resched() is not called in scan_swap_map_slots()).  Let's add
cond_resched() into get_swap_pages() when failed to find available space
to avoid softlockup.

Link: https://lkml.kernel.org/r/20230128094757.1060525-1-xialonglong1@huawei.comSigned-off-by: NLonglong Xia <xialonglong1@huawei.com>
Reviewed-by: N"Huang, Ying" <ying.huang@intel.com>
Cc: Chen Wandun <chenwandun@huawei.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Nanyong Sun <sunnanyong@huawei.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NZhangPeng <zhangpeng362@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      010c4efc
    • Z
      mm: slince possible data races about pgdat->kswapd · c91859b6
      由 ZhangPeng 提交于 
      maillist inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6PKGM

Reference: https://lore.kernel.org/linux-mm/20220824071909.192535-1-wangkefeng.wang@huawei.com/

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

The pgdat->kswapd could be accessed concurrently by kswapd_run() and
kcompactd(), it don't be protected by any lock, which could leads to
data races, adding READ/WRITE_ONCE() to slince it.
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>

Conflicts:
	mm/compaction.c
	mm/vmscan.c
Signed-off-by: NZhangPeng <zhangpeng362@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      c91859b6
    • Z
      mm: fix null-ptr-deref in kswapd_is_running() · d569f7f9
      由 ZhangPeng 提交于 
      maillist inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6PKGM

Reference: https://lore.kernel.org/linux-mm/20220824071909.192535-1-wangkefeng.wang@huawei.com/

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

wapd_run/stop() will set pgdat->kswapd to NULL, which could race with
kswapd_is_running() in kcompactd(),

kswapd_run/stop()	kcompactd()
			  kswapd_is_running()
				if (pgdat->kswapd) // load non-NULL pgdat->kswapd
  pgdat->kswapd = NULL
				task_is_running(pgdat->kswapd) // Null pointer derefence

The KASAN report the null-ptr-deref shown below,

  vmscan: Failed to start kswapd on node 0
  ...
  BUG: KASAN: null-ptr-deref in kcompactd+0x440/0x504
  Read of size 8 at addr 0000000000000024 by task kcompactd0/37

  CPU: 0 PID: 37 Comm: kcompactd0 Kdump: loaded Tainted: G OE 5.10.60 #1
  Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
  Call trace:
   dump_backtrace+0x0/0x394
   show_stack+0x34/0x4c
   dump_stack+0x158/0x1e4
   __kasan_report+0x138/0x140
   kasan_report+0x44/0xdc
   __asan_load8+0x94/0xd0
   kcompactd+0x440/0x504
   kthread+0x1a4/0x1f0
   ret_from_fork+0x10/0x18

For race between kswapd_run() and kcompactd(), adding a temporary value
when create a kthread, and only set it to pgdat->kswapd if kthread_run()
return successful task_struct to fix the issue.

For race between kswapd_stop() and kcompactd(), let's call
kcompactd_stop() before kswapd_stop() to fix the issue.
Signed-off-by: NKefeng Wang <wangkefeng.wang@huawei.com>

Conflicts:
	mm/vmscan.c
Signed-off-by: NZhangPeng <zhangpeng362@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      d569f7f9
    • E
      fs/ntfs3: Validate MFT flags before replaying logs · 447350f6
      由 Edward Lo 提交于 
      maillist inclusion
category: bugfix
bugzilla: 188564, https://gitee.com/src-openeuler/kernel/issues/I6OD5R
CVE: CVE-2022-48425

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/fs/ntfs3?id=467333af2f7b95eeaa61a5b5369a80063cd971fd

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

Log load and replay is part of the metadata handle flow during mount
operation. The $MFT record will be loaded and used while replaying logs.
However, a malformed $MFT record, say, has RECORD_FLAG_DIR flag set and
contains an ATTR_ROOT attribute will misguide kernel to treat it as a
directory, and try to free the allocated resources when the
corresponding inode is freed, which will cause an invalid kfree because
the memory hasn't actually been allocated.

[  101.368647] BUG: KASAN: invalid-free in kvfree+0x2c/0x40
[  101.369457]
[  101.369986] CPU: 0 PID: 198 Comm: mount Not tainted 6.0.0-rc7+ #5
[  101.370529] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[  101.371362] Call Trace:
[  101.371795]  <TASK>
[  101.372157]  dump_stack_lvl+0x49/0x63
[  101.372658]  print_report.cold+0xf5/0x689
[  101.373022]  ? ni_write_inode+0x754/0xd90
[  101.373378]  ? kvfree+0x2c/0x40
[  101.373698]  kasan_report_invalid_free+0x77/0xf0
[  101.374058]  ? kvfree+0x2c/0x40
[  101.374352]  ? kvfree+0x2c/0x40
[  101.374668]  __kasan_slab_free+0x189/0x1b0
[  101.374992]  ? kvfree+0x2c/0x40
[  101.375271]  kfree+0x168/0x3b0
[  101.375717]  kvfree+0x2c/0x40
[  101.376002]  indx_clear+0x26/0x60
[  101.376316]  ni_clear+0xc5/0x290
[  101.376661]  ntfs_evict_inode+0x45/0x70
[  101.377001]  evict+0x199/0x280
[  101.377432]  iput.part.0+0x286/0x320
[  101.377819]  iput+0x32/0x50
[  101.378166]  ntfs_loadlog_and_replay+0x143/0x320
[  101.378656]  ? ntfs_bio_fill_1+0x510/0x510
[  101.378968]  ? iput.part.0+0x286/0x320
[  101.379367]  ntfs_fill_super+0xecb/0x1ba0
[  101.379729]  ? put_ntfs+0x1d0/0x1d0
[  101.380046]  ? vsprintf+0x20/0x20
[  101.380542]  ? mutex_unlock+0x81/0xd0
[  101.380914]  ? set_blocksize+0x95/0x150
[  101.381597]  get_tree_bdev+0x232/0x370
[  101.382254]  ? put_ntfs+0x1d0/0x1d0
[  101.382699]  ntfs_fs_get_tree+0x15/0x20
[  101.383094]  vfs_get_tree+0x4c/0x130
[  101.383675]  path_mount+0x654/0xfe0
[  101.384203]  ? putname+0x80/0xa0
[  101.384540]  ? finish_automount+0x2e0/0x2e0
[  101.384943]  ? putname+0x80/0xa0
[  101.385362]  ? kmem_cache_free+0x1c4/0x440
[  101.385968]  ? putname+0x80/0xa0
[  101.386666]  do_mount+0xd6/0xf0
[  101.387228]  ? path_mount+0xfe0/0xfe0
[  101.387585]  ? __kasan_check_write+0x14/0x20
[  101.387979]  __x64_sys_mount+0xca/0x110
[  101.388436]  do_syscall_64+0x3b/0x90
[  101.388757]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  101.389289] RIP: 0033:0x7fa0f70e948a
[  101.390048] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008
[  101.391297] RSP: 002b:00007ffc24fdecc8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
[  101.391988] RAX: ffffffffffffffda RBX: 000055932c183060 RCX: 00007fa0f70e948a
[  101.392494] RDX: 000055932c183260 RSI: 000055932c1832e0 RDI: 000055932c18bce0
[  101.393053] RBP: 0000000000000000 R08: 000055932c183280 R09: 0000000000000020
[  101.393577] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 000055932c18bce0
[  101.394044] R13: 000055932c183260 R14: 0000000000000000 R15: 00000000ffffffff
[  101.394747]  </TASK>
[  101.395402]
[  101.396047] Allocated by task 198:
[  101.396724]  kasan_save_stack+0x26/0x50
[  101.397400]  __kasan_slab_alloc+0x6d/0x90
[  101.397974]  kmem_cache_alloc_lru+0x192/0x5a0
[  101.398524]  ntfs_alloc_inode+0x23/0x70
[  101.399137]  alloc_inode+0x3b/0xf0
[  101.399534]  iget5_locked+0x54/0xa0
[  101.400026]  ntfs_iget5+0xaf/0x1780
[  101.400414]  ntfs_loadlog_and_replay+0xe5/0x320
[  101.400883]  ntfs_fill_super+0xecb/0x1ba0
[  101.401313]  get_tree_bdev+0x232/0x370
[  101.401774]  ntfs_fs_get_tree+0x15/0x20
[  101.402224]  vfs_get_tree+0x4c/0x130
[  101.402673]  path_mount+0x654/0xfe0
[  101.403160]  do_mount+0xd6/0xf0
[  101.403537]  __x64_sys_mount+0xca/0x110
[  101.404058]  do_syscall_64+0x3b/0x90
[  101.404333]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  101.404816]
[  101.405067] The buggy address belongs to the object at ffff888008cc9ea0
[  101.405067]  which belongs to the cache ntfs_inode_cache of size 992
[  101.406171] The buggy address is located 232 bytes inside of
[  101.406171]  992-byte region [ffff888008cc9ea0, ffff888008cca280)
[  101.406995]
[  101.408559] The buggy address belongs to the physical page:
[  101.409320] page:00000000dccf19dd refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cc8
[  101.410654] head:00000000dccf19dd order:2 compound_mapcount:0 compound_pincount:0
[  101.411533] flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
[  101.412665] raw: 000fffffc0010200 0000000000000000 dead000000000122 ffff888003695140
[  101.413209] raw: 0000000000000000 00000000800e000e 00000001ffffffff 0000000000000000
[  101.413799] page dumped because: kasan: bad access detected
[  101.414213]
[  101.414427] Memory state around the buggy address:
[  101.414991]  ffff888008cc9e80: fc fc fc fc 00 00 00 00 00 00 00 00 00 00 00 00
[  101.415785]  ffff888008cc9f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  101.416933] >ffff888008cc9f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  101.417857]                       ^
[  101.418566]  ffff888008cca000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[  101.419704]  ffff888008cca080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Signed-off-by: NEdward Lo <edward.lo@ambergroup.io>
Signed-off-by: NKonstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: NZhong Jinghua <zhongjinghua@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>
      447350f6
    • E
      fs/ntfs3: Validate attribute name offset · 887a9199
      由 Edward Lo 提交于 
      maillist inclusion
category: bugfix
bugzilla: 188564, https://gitee.com/src-openeuler/kernel/issues/I6OD4P
CVE: CVE-2022-48424

Reference: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4f1dc7d9756e66f3f876839ea174df2e656b7f79

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

Although the attribute name length is checked before comparing it to
some common names (e.g., $I30), the offset isn't. This adds a sanity
check for the attribute name offset, guarantee the validity and prevent
possible out-of-bound memory accesses.

[  191.720056] BUG: unable to handle page fault for address: ffffebde00000008
[  191.721060] #PF: supervisor read access in kernel mode
[  191.721586] #PF: error_code(0x0000) - not-present page
[  191.722079] PGD 0 P4D 0
[  191.722571] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI
[  191.723179] CPU: 0 PID: 244 Comm: mount Not tainted 6.0.0-rc4 #28
[  191.723749] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[  191.724832] RIP: 0010:kfree+0x56/0x3b0
[  191.725870] Code: 80 48 01 d8 0f 82 65 03 00 00 48 c7 c2 00 00 00 80 48 2b 15 2c 06 dd 01 48 01 d0 48 c1 e8 0c 48 c1 e0 06 48 03 05 0a 069
[  191.727375] RSP: 0018:ffff8880076f7878 EFLAGS: 00000286
[  191.727897] RAX: ffffebde00000000 RBX: 0000000000000040 RCX: ffffffff8528d5b9
[  191.728531] RDX: 0000777f80000000 RSI: ffffffff8522d49c RDI: 0000000000000040
[  191.729183] RBP: ffff8880076f78a0 R08: 0000000000000000 R09: 0000000000000000
[  191.729628] R10: ffff888008949fd8 R11: ffffed10011293fd R12: 0000000000000040
[  191.730158] R13: ffff888008949f98 R14: ffff888008949ec0 R15: ffff888008949fb0
[  191.730645] FS:  00007f3520cd7e40(0000) GS:ffff88805ba00000(0000) knlGS:0000000000000000
[  191.731328] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  191.731667] CR2: ffffebde00000008 CR3: 0000000009704000 CR4: 00000000000006f0
[  191.732568] Call Trace:
[  191.733231]  <TASK>
[  191.733860]  kvfree+0x2c/0x40
[  191.734632]  ni_clear+0x180/0x290
[  191.735085]  ntfs_evict_inode+0x45/0x70
[  191.735495]  evict+0x199/0x280
[  191.735996]  iput.part.0+0x286/0x320
[  191.736438]  iput+0x32/0x50
[  191.736811]  iget_failed+0x23/0x30
[  191.737270]  ntfs_iget5+0x337/0x1890
[  191.737629]  ? ntfs_clear_mft_tail+0x20/0x260
[  191.738201]  ? ntfs_get_block_bmap+0x70/0x70
[  191.738482]  ? ntfs_objid_init+0xf6/0x140
[  191.738779]  ? ntfs_reparse_init+0x140/0x140
[  191.739266]  ntfs_fill_super+0x121b/0x1b50
[  191.739623]  ? put_ntfs+0x1d0/0x1d0
[  191.739984]  ? asm_sysvec_apic_timer_interrupt+0x1b/0x20
[  191.740466]  ? put_ntfs+0x1d0/0x1d0
[  191.740787]  ? sb_set_blocksize+0x6a/0x80
[  191.741272]  get_tree_bdev+0x232/0x370
[  191.741829]  ? put_ntfs+0x1d0/0x1d0
[  191.742669]  ntfs_fs_get_tree+0x15/0x20
[  191.743132]  vfs_get_tree+0x4c/0x130
[  191.743457]  path_mount+0x654/0xfe0
[  191.743938]  ? putname+0x80/0xa0
[  191.744271]  ? finish_automount+0x2e0/0x2e0
[  191.744582]  ? putname+0x80/0xa0
[  191.745053]  ? kmem_cache_free+0x1c4/0x440
[  191.745403]  ? putname+0x80/0xa0
[  191.745616]  do_mount+0xd6/0xf0
[  191.745887]  ? path_mount+0xfe0/0xfe0
[  191.746287]  ? __kasan_check_write+0x14/0x20
[  191.746582]  __x64_sys_mount+0xca/0x110
[  191.746850]  do_syscall_64+0x3b/0x90
[  191.747122]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  191.747517] RIP: 0033:0x7f351fee948a
[  191.748332] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008
[  191.749341] RSP: 002b:00007ffd51cf3af8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
[  191.749960] RAX: ffffffffffffffda RBX: 000055b903733060 RCX: 00007f351fee948a
[  191.750589] RDX: 000055b903733260 RSI: 000055b9037332e0 RDI: 000055b90373bce0
[  191.751115] RBP: 0000000000000000 R08: 000055b903733280 R09: 0000000000000020
[  191.751537] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 000055b90373bce0
[  191.751946] R13: 000055b903733260 R14: 0000000000000000 R15: 00000000ffffffff
[  191.752519]  </TASK>
[  191.752782] Modules linked in:
[  191.753785] CR2: ffffebde00000008
[  191.754937] ---[ end trace 0000000000000000 ]---
[  191.755429] RIP: 0010:kfree+0x56/0x3b0
[  191.755725] Code: 80 48 01 d8 0f 82 65 03 00 00 48 c7 c2 00 00 00 80 48 2b 15 2c 06 dd 01 48 01 d0 48 c1 e8 0c 48 c1 e0 06 48 03 05 0a 069
[  191.756744] RSP: 0018:ffff8880076f7878 EFLAGS: 00000286
[  191.757218] RAX: ffffebde00000000 RBX: 0000000000000040 RCX: ffffffff8528d5b9
[  191.757580] RDX: 0000777f80000000 RSI: ffffffff8522d49c RDI: 0000000000000040
[  191.758016] RBP: ffff8880076f78a0 R08: 0000000000000000 R09: 0000000000000000
[  191.758570] R10: ffff888008949fd8 R11: ffffed10011293fd R12: 0000000000000040
[  191.758957] R13: ffff888008949f98 R14: ffff888008949ec0 R15: ffff888008949fb0
[  191.759317] FS:  00007f3520cd7e40(0000) GS:ffff88805ba00000(0000) knlGS:0000000000000000
[  191.759711] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  191.760118] CR2: ffffebde00000008 CR3: 0000000009704000 CR4: 00000000000006f0
Signed-off-by: NEdward Lo <edward.lo@ambergroup.io>
Signed-off-by: NKonstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: NZhong Jinghua <zhongjinghua@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>
      887a9199
    • E
      bpf: Fixes possible race in update_prog_stats() for 32bit arches · 3bbe35c8
      由 Eric Dumazet 提交于 
      mainline inclusion
from mainline-v5.16-rc1
commit d979617a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6O293

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

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

It seems update_prog_stats() suffers from same issue fixed
in the prior patch:

As it can run while interrupts are enabled, it could
be re-entered and the u64_stats syncp could be mangled.

Fixes: fec56f58 ("bpf: Introduce BPF trampoline")
Signed-off-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20211026214133.3114279-3-eric.dumazet@gmail.com
Conflicts:
	kernel/bpf/trampoline.c
Signed-off-by: NPu Lehui <pulehui@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      3bbe35c8
    • E
      bpf: Avoid races in __bpf_prog_run() for 32bit arches · 00a8fd48
      由 Eric Dumazet 提交于 
      mainline inclusion
from mainline-v5.16-rc1
commit f941eadd
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6O293

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.3-rc3&id=f941eadd8d6d4ee2f8c9aeab8e1da5e647533a7d

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

__bpf_prog_run() can run from non IRQ contexts, meaning
it could be re entered if interrupted.

This calls for the irq safe variant of u64_stats_update_{begin|end},
or risk a deadlock.

This patch is a nop on 64bit arches, fortunately.

syzbot report:

WARNING: inconsistent lock state
5.12.0-rc3-syzkaller #0 Not tainted
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
udevd/4013 [HC0[0]:SC0[0]:HE1:SE1] takes:
ff7c9dec (&(&pstats->syncp)->seq){+.?.}-{0:0}, at: sk_filter include/linux/filter.h:867 [inline]
ff7c9dec (&(&pstats->syncp)->seq){+.?.}-{0:0}, at: do_one_broadcast net/netlink/af_netlink.c:1468 [inline]
ff7c9dec (&(&pstats->syncp)->seq){+.?.}-{0:0}, at: netlink_broadcast_filtered+0x27c/0x4fc net/netlink/af_netlink.c:1520
{IN-SOFTIRQ-W} state was registered at:
  lock_acquire.part.0+0xf0/0x41c kernel/locking/lockdep.c:5510
  lock_acquire+0x6c/0x74 kernel/locking/lockdep.c:5483
  do_write_seqcount_begin_nested include/linux/seqlock.h:520 [inline]
  do_write_seqcount_begin include/linux/seqlock.h:545 [inline]
  u64_stats_update_begin include/linux/u64_stats_sync.h:129 [inline]
  bpf_prog_run_pin_on_cpu include/linux/filter.h:624 [inline]
  bpf_prog_run_clear_cb+0x1bc/0x270 include/linux/filter.h:755
  run_filter+0xa0/0x17c net/packet/af_packet.c:2031
  packet_rcv+0xc0/0x3e0 net/packet/af_packet.c:2104
  dev_queue_xmit_nit+0x2bc/0x39c net/core/dev.c:2387
  xmit_one net/core/dev.c:3588 [inline]
  dev_hard_start_xmit+0x94/0x518 net/core/dev.c:3609
  sch_direct_xmit+0x11c/0x1f0 net/sched/sch_generic.c:313
  qdisc_restart net/sched/sch_generic.c:376 [inline]
  __qdisc_run+0x194/0x7f8 net/sched/sch_generic.c:384
  qdisc_run include/net/pkt_sched.h:136 [inline]
  qdisc_run include/net/pkt_sched.h:128 [inline]
  __dev_xmit_skb net/core/dev.c:3795 [inline]
  __dev_queue_xmit+0x65c/0xf84 net/core/dev.c:4150
  dev_queue_xmit+0x14/0x18 net/core/dev.c:4215
  neigh_resolve_output net/core/neighbour.c:1491 [inline]
  neigh_resolve_output+0x170/0x228 net/core/neighbour.c:1471
  neigh_output include/net/neighbour.h:510 [inline]
  ip6_finish_output2+0x2e4/0x9fc net/ipv6/ip6_output.c:117
  __ip6_finish_output net/ipv6/ip6_output.c:182 [inline]
  __ip6_finish_output+0x164/0x3f8 net/ipv6/ip6_output.c:161
  ip6_finish_output+0x2c/0xb0 net/ipv6/ip6_output.c:192
  NF_HOOK_COND include/linux/netfilter.h:290 [inline]
  ip6_output+0x74/0x294 net/ipv6/ip6_output.c:215
  dst_output include/net/dst.h:448 [inline]
  NF_HOOK include/linux/netfilter.h:301 [inline]
  NF_HOOK include/linux/netfilter.h:295 [inline]
  mld_sendpack+0x2a8/0x7e4 net/ipv6/mcast.c:1679
  mld_send_cr net/ipv6/mcast.c:1975 [inline]
  mld_ifc_timer_expire+0x1e8/0x494 net/ipv6/mcast.c:2474
  call_timer_fn+0xd0/0x570 kernel/time/timer.c:1431
  expire_timers kernel/time/timer.c:1476 [inline]
  __run_timers kernel/time/timer.c:1745 [inline]
  run_timer_softirq+0x2e4/0x384 kernel/time/timer.c:1758
  __do_softirq+0x204/0x7ac kernel/softirq.c:345
  do_softirq_own_stack include/asm-generic/softirq_stack.h:10 [inline]
  invoke_softirq kernel/softirq.c:228 [inline]
  __irq_exit_rcu+0x1d8/0x200 kernel/softirq.c:422
  irq_exit+0x10/0x3c kernel/softirq.c:446
  __handle_domain_irq+0xb4/0x120 kernel/irq/irqdesc.c:692
  handle_domain_irq include/linux/irqdesc.h:176 [inline]
  gic_handle_irq+0x84/0xac drivers/irqchip/irq-gic.c:370
  __irq_svc+0x5c/0x94 arch/arm/kernel/entry-armv.S:205
  debug_smp_processor_id+0x0/0x24 lib/smp_processor_id.c:53
  rcu_read_lock_held_common kernel/rcu/update.c:108 [inline]
  rcu_read_lock_sched_held+0x24/0x7c kernel/rcu/update.c:123
  trace_lock_acquire+0x24c/0x278 include/trace/events/lock.h:13
  lock_acquire+0x3c/0x74 kernel/locking/lockdep.c:5481
  rcu_lock_acquire include/linux/rcupdate.h:267 [inline]
  rcu_read_lock include/linux/rcupdate.h:656 [inline]
  avc_has_perm_noaudit+0x6c/0x260 security/selinux/avc.c:1150
  selinux_inode_permission+0x140/0x220 security/selinux/hooks.c:3141
  security_inode_permission+0x44/0x60 security/security.c:1268
  inode_permission.part.0+0x5c/0x13c fs/namei.c:521
  inode_permission fs/namei.c:494 [inline]
  may_lookup fs/namei.c:1652 [inline]
  link_path_walk.part.0+0xd4/0x38c fs/namei.c:2208
  link_path_walk fs/namei.c:2189 [inline]
  path_lookupat+0x3c/0x1b8 fs/namei.c:2419
  filename_lookup+0xa8/0x1a4 fs/namei.c:2453
  user_path_at_empty+0x74/0x90 fs/namei.c:2733
  do_readlinkat+0x5c/0x12c fs/stat.c:417
  __do_sys_readlink fs/stat.c:450 [inline]
  sys_readlink+0x24/0x28 fs/stat.c:447
  ret_fast_syscall+0x0/0x2c arch/arm/mm/proc-v7.S:64
  0x7eaa4974
irq event stamp: 298277
hardirqs last  enabled at (298277): [<802000d0>] no_work_pending+0x4/0x34
hardirqs last disabled at (298276): [<8020c9b8>] do_work_pending+0x9c/0x648 arch/arm/kernel/signal.c:676
softirqs last  enabled at (298216): [<8020167c>] __do_softirq+0x584/0x7ac kernel/softirq.c:372
softirqs last disabled at (298201): [<8024dff4>] do_softirq_own_stack include/asm-generic/softirq_stack.h:10 [inline]
softirqs last disabled at (298201): [<8024dff4>] invoke_softirq kernel/softirq.c:228 [inline]
softirqs last disabled at (298201): [<8024dff4>] __irq_exit_rcu+0x1d8/0x200 kernel/softirq.c:422

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&pstats->syncp)->seq);
  <Interrupt>
    lock(&(&pstats->syncp)->seq);

 *** DEADLOCK ***

1 lock held by udevd/4013:
 #0: 82b09c5c (rcu_read_lock){....}-{1:2}, at: sk_filter_trim_cap+0x54/0x434 net/core/filter.c:139

stack backtrace:
CPU: 1 PID: 4013 Comm: udevd Not tainted 5.12.0-rc3-syzkaller #0
Hardware name: ARM-Versatile Express
Backtrace:
[<81802550>] (dump_backtrace) from [<818027c4>] (show_stack+0x18/0x1c arch/arm/kernel/traps.c:252)
 r7:00000080 r6:600d0093 r5:00000000 r4:82b58344
[<818027ac>] (show_stack) from [<81809e98>] (__dump_stack lib/dump_stack.c:79 [inline])
[<818027ac>] (show_stack) from [<81809e98>] (dump_stack+0xb8/0xe8 lib/dump_stack.c:120)
[<81809de0>] (dump_stack) from [<81804a00>] (print_usage_bug.part.0+0x228/0x230 kernel/locking/lockdep.c:3806)
 r7:86bcb768 r6:81a0326c r5:830f96a8 r4:86bcb0c0
[<818047d8>] (print_usage_bug.part.0) from [<802bb1b8>] (print_usage_bug kernel/locking/lockdep.c:3776 [inline])
[<818047d8>] (print_usage_bug.part.0) from [<802bb1b8>] (valid_state kernel/locking/lockdep.c:3818 [inline])
[<818047d8>] (print_usage_bug.part.0) from [<802bb1b8>] (mark_lock_irq kernel/locking/lockdep.c:4021 [inline])
[<818047d8>] (print_usage_bug.part.0) from [<802bb1b8>] (mark_lock.part.0+0xc34/0x136c kernel/locking/lockdep.c:4478)
 r10:83278fe8 r9:82c6d748 r8:00000000 r7:82c6d2d4 r6:00000004 r5:86bcb768
 r4:00000006
[<802ba584>] (mark_lock.part.0) from [<802bc644>] (mark_lock kernel/locking/lockdep.c:4442 [inline])
[<802ba584>] (mark_lock.part.0) from [<802bc644>] (mark_usage kernel/locking/lockdep.c:4391 [inline])
[<802ba584>] (mark_lock.part.0) from [<802bc644>] (__lock_acquire+0x9bc/0x3318 kernel/locking/lockdep.c:4854)
 r10:86bcb768 r9:86bcb0c0 r8:00000001 r7:00040000 r6:0000075a r5:830f96a8
 r4:00000000
[<802bbc88>] (__lock_acquire) from [<802bfb90>] (lock_acquire.part.0+0xf0/0x41c kernel/locking/lockdep.c:5510)
 r10:00000000 r9:600d0013 r8:00000000 r7:00000000 r6:828a2680 r5:828a2680
 r4:861e5bc8
[<802bfaa0>] (lock_acquire.part.0) from [<802bff28>] (lock_acquire+0x6c/0x74 kernel/locking/lockdep.c:5483)
 r10:8146137c r9:00000000 r8:00000001 r7:00000000 r6:00000000 r5:00000000
 r4:ff7c9dec
[<802bfebc>] (lock_acquire) from [<81381eb4>] (do_write_seqcount_begin_nested include/linux/seqlock.h:520 [inline])
[<802bfebc>] (lock_acquire) from [<81381eb4>] (do_write_seqcount_begin include/linux/seqlock.h:545 [inline])
[<802bfebc>] (lock_acquire) from [<81381eb4>] (u64_stats_update_begin include/linux/u64_stats_sync.h:129 [inline])
[<802bfebc>] (lock_acquire) from [<81381eb4>] (__bpf_prog_run_save_cb include/linux/filter.h:727 [inline])
[<802bfebc>] (lock_acquire) from [<81381eb4>] (bpf_prog_run_save_cb include/linux/filter.h:741 [inline])
[<802bfebc>] (lock_acquire) from [<81381eb4>] (sk_filter_trim_cap+0x26c/0x434 net/core/filter.c:149)
 r10:a4095dd0 r9:ff7c9dd0 r8:e44be000 r7:8146137c r6:00000001 r5:8611ba80
 r4:00000000
[<81381c48>] (sk_filter_trim_cap) from [<8146137c>] (sk_filter include/linux/filter.h:867 [inline])
[<81381c48>] (sk_filter_trim_cap) from [<8146137c>] (do_one_broadcast net/netlink/af_netlink.c:1468 [inline])
[<81381c48>] (sk_filter_trim_cap) from [<8146137c>] (netlink_broadcast_filtered+0x27c/0x4fc net/netlink/af_netlink.c:1520)
 r10:00000001 r9:833d6b1c r8:00000000 r7:8572f864 r6:8611ba80 r5:8698d800
 r4:8572f800
[<81461100>] (netlink_broadcast_filtered) from [<81463e60>] (netlink_broadcast net/netlink/af_netlink.c:1544 [inline])
[<81461100>] (netlink_broadcast_filtered) from [<81463e60>] (netlink_sendmsg+0x3d0/0x478 net/netlink/af_netlink.c:1925)
 r10:00000000 r9:00000002 r8:8698d800 r7:000000b7 r6:8611b900 r5:861e5f50
 r4:86aa3000
[<81463a90>] (netlink_sendmsg) from [<81321f54>] (sock_sendmsg_nosec net/socket.c:654 [inline])
[<81463a90>] (netlink_sendmsg) from [<81321f54>] (sock_sendmsg+0x3c/0x4c net/socket.c:674)
 r10:00000000 r9:861e5dd4 r8:00000000 r7:86570000 r6:00000000 r5:86570000
 r4:861e5f50
[<81321f18>] (sock_sendmsg) from [<813234d0>] (____sys_sendmsg+0x230/0x29c net/socket.c:2350)
 r5:00000040 r4:861e5f50
[<813232a0>] (____sys_sendmsg) from [<8132549c>] (___sys_sendmsg+0xac/0xe4 net/socket.c:2404)
 r10:00000128 r9:861e4000 r8:00000000 r7:00000000 r6:86570000 r5:861e5f50
 r4:00000000
[<813253f0>] (___sys_sendmsg) from [<81325684>] (__sys_sendmsg net/socket.c:2433 [inline])
[<813253f0>] (___sys_sendmsg) from [<81325684>] (__do_sys_sendmsg net/socket.c:2442 [inline])
[<813253f0>] (___sys_sendmsg) from [<81325684>] (sys_sendmsg+0x58/0xa0 net/socket.c:2440)
 r8:80200224 r7:00000128 r6:00000000 r5:7eaa541c r4:86570000
[<8132562c>] (sys_sendmsg) from [<80200060>] (ret_fast_syscall+0x0/0x2c arch/arm/mm/proc-v7.S:64)
Exception stack(0x861e5fa8 to 0x861e5ff0)
5fa0:                   00000000 00000000 0000000c 7eaa541c 00000000 00000000
5fc0: 00000000 00000000 76fbf840 00000128 00000000 0000008f 7eaa541c 000563f8
5fe0: 00056110 7eaa53e0 00036cec 76c9bf44
 r6:76fbf840 r5:00000000 r4:00000000

Fixes: 492ecee8 ("bpf: enable program stats")
Reported-by: Nsyzbot <syzkaller@googlegroups.com>
Signed-off-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20211026214133.3114279-2-eric.dumazet@gmail.com
Conflicts:
	include/linux/filter.h
Signed-off-by: NPu Lehui <pulehui@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      00a8fd48
    • Y
      ext4: make sure fs error flag setted before clear journal error · 6546b303
      由 Ye Bin 提交于 
      mainline inclusion
from mainline-v6.3-rc2
commit f57886ca
category: bugfix
bugzilla: 188471,https://gitee.com/openeuler/kernel/issues/I6MR1V
CVE: NA

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

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

Now, jounral error number maybe cleared even though ext4_commit_super()
failed. This may lead to error flag miss, then fsck will miss to check
file system deeply.
Signed-off-by: NYe Bin <yebin10@huawei.com>
Reviewed-by: NJan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20230307061703.245965-3-yebin@huaweicloud.comSigned-off-by: NBaokun Li <libaokun1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NYang Erkun <yangerkun@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      6546b303
    • Y
      ext4: commit super block if fs record error when journal record without error · 04933ef6
      由 Ye Bin 提交于 
      mainline inclusion
from mainline-v6.3-rc2
commit eee00237
category: bugfix
bugzilla: 188471,https://gitee.com/openeuler/kernel/issues/I6MR1V
CVE: NA

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

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

Now, 'es->s_state' maybe covered by recover journal. And journal errno
maybe not recorded in journal sb as IO error. ext4_update_super() only
update error information when 'sbi->s_add_error_count' large than zero.
Then 'EXT4_ERROR_FS' flag maybe lost.
To solve above issue just recover 'es->s_state' error flag after journal
replay like error info.
Signed-off-by: NYe Bin <yebin10@huawei.com>
Reviewed-by: NBaokun Li <libaokun1@huawei.com>
Reviewed-by: NJan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20230307061703.245965-2-yebin@huaweicloud.comSigned-off-by: NBaokun Li <libaokun1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NYang Erkun <yangerkun@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      04933ef6
    • K
      af_unix: Get user_ns from in_skb in unix_diag_get_exact(). · 8063779e
      由 Kuniyuki Iwashima 提交于 
      stable inclusion
from stable-v5.10.158
commit 575a6266f63dbb3b8eb1da03671451f0d81b8034
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6NCP2
CVE: CVE-2023-28327

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

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

[ Upstream commit b3abe42e ]

Wei Chen reported a NULL deref in sk_user_ns() [0][1], and Paolo diagnosed
the root cause: in unix_diag_get_exact(), the newly allocated skb does not
have sk. [2]

We must get the user_ns from the NETLINK_CB(in_skb).sk and pass it to
sk_diag_fill().

[0]:
BUG: kernel NULL pointer dereference, address: 0000000000000270
PGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 0 PID: 27942 Comm: syz-executor.0 Not tainted 6.1.0-rc5-next-20221118 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
RIP: 0010:sk_user_ns include/net/sock.h:920 [inline]
RIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [inline]
RIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170
Code: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8
54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd <48> 8b
9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d
RSP: 0018:ffffc90000d67968 EFLAGS: 00010246
RAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ffffffff840d481d
RDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270
RBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000
R10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800
R13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940
FS:  00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 unix_diag_get_exact net/unix/diag.c:285 [inline]
 unix_diag_handler_dump+0x3f9/0x500 net/unix/diag.c:317
 __sock_diag_cmd net/core/sock_diag.c:235 [inline]
 sock_diag_rcv_msg+0x237/0x250 net/core/sock_diag.c:266
 netlink_rcv_skb+0x13e/0x250 net/netlink/af_netlink.c:2564
 sock_diag_rcv+0x24/0x40 net/core/sock_diag.c:277
 netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]
 netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1356
 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1932
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg net/socket.c:734 [inline]
 ____sys_sendmsg+0x38f/0x500 net/socket.c:2476
 ___sys_sendmsg net/socket.c:2530 [inline]
 __sys_sendmsg+0x197/0x230 net/socket.c:2559
 __do_sys_sendmsg net/socket.c:2568 [inline]
 __se_sys_sendmsg net/socket.c:2566 [inline]
 __x64_sys_sendmsg+0x42/0x50 net/socket.c:2566
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x4697f9
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f08b4e6ec48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9
RDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003
RBP: 00000000004d29e9 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf80
R13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffdb36bc6c0
 </TASK>
Modules linked in:
CR2: 0000000000000270

[1]: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/
[2]: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/

Fixes: cae9910e ("net: Add UNIX_DIAG_UID to Netlink UNIX socket diagnostics.")
Reported-by: Nsyzbot <syzkaller@googlegroups.com>
Reported-by: NWei Chen <harperchen1110@gmail.com>
Diagnosed-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      8063779e
    • H
      net: tls: fix possible race condition between do_tls_getsockopt_conf() and do_tls_setsockopt_conf() · 0267c66e
      由 Hangyu Hua 提交于 
      mainline inclusion
from mainline-v6.3-rc2
commit 49c47cc2
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6NIUR
CVE: CVE-2023-28466

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

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

ctx->crypto_send.info is not protected by lock_sock in
do_tls_getsockopt_conf(). A race condition between do_tls_getsockopt_conf()
and error paths of do_tls_setsockopt_conf() may lead to a use-after-free
or null-deref.

More discussion:  https://lore.kernel.org/all/Y/ht6gQL+u6fj3dG@hog/

Fixes: 3c4d7559 ("tls: kernel TLS support")
Signed-off-by: NHangyu Hua <hbh25y@gmail.com>
Link: https://lore.kernel.org/r/20230228023344.9623-1-hbh25y@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NLiu Jian <liujian56@huawei.com>

Conflicts:
	net/tls/tls_main.c
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      0267c66e
    • J
      wifi: brcmfmac: slab-out-of-bounds read in brcmf_get_assoc_ies() · 8a2a4e91
      由 Jisoo Jang 提交于 
      maillist inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6NCVX
CVE: CVE-2023-1380

Reference: https://patchwork.kernel.org/project/linux-wireless/patch/20230309104457.22628-1-jisoo.jang@yonsei.ac.kr/

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

Fix a slab-out-of-bounds read that occurs in kmemdup() called from
brcmf_get_assoc_ies().
The bug could occur when assoc_info->req_len, data from a URB provided
by a USB device, is bigger than the size of buffer which is defined as
WL_EXTRA_BUF_MAX.

Add the size check for req_len/resp_len of assoc_info.

Found by a modified version of syzkaller.

[   46.592467][    T7] ==================================================================
[   46.594687][    T7] BUG: KASAN: slab-out-of-bounds in kmemdup+0x3e/0x50
[   46.596572][    T7] Read of size 3014656 at addr ffff888019442000 by task kworker/0:1/7
[   46.598575][    T7]
[   46.599157][    T7] CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G           O      5.14.0+ #145
[   46.601333][    T7] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[   46.604360][    T7] Workqueue: events brcmf_fweh_event_worker
[   46.605943][    T7] Call Trace:
[   46.606584][    T7]  dump_stack_lvl+0x8e/0xd1
[   46.607446][    T7]  print_address_description.constprop.0.cold+0x93/0x334
[   46.608610][    T7]  ? kmemdup+0x3e/0x50
[   46.609341][    T7]  kasan_report.cold+0x79/0xd5
[   46.610151][    T7]  ? kmemdup+0x3e/0x50
[   46.610796][    T7]  kasan_check_range+0x14e/0x1b0
[   46.611691][    T7]  memcpy+0x20/0x60
[   46.612323][    T7]  kmemdup+0x3e/0x50
[   46.612987][    T7]  brcmf_get_assoc_ies+0x967/0xf60
[   46.613904][    T7]  ? brcmf_notify_vif_event+0x3d0/0x3d0
[   46.614831][    T7]  ? lock_chain_count+0x20/0x20
[   46.615683][    T7]  ? mark_lock.part.0+0xfc/0x2770
[   46.616552][    T7]  ? lock_chain_count+0x20/0x20
[   46.617409][    T7]  ? mark_lock.part.0+0xfc/0x2770
[   46.618244][    T7]  ? lock_chain_count+0x20/0x20
[   46.619024][    T7]  brcmf_bss_connect_done.constprop.0+0x241/0x2e0
[   46.620019][    T7]  ? brcmf_parse_configure_security.isra.0+0x2a0/0x2a0
[   46.620818][    T7]  ? __lock_acquire+0x181f/0x5790
[   46.621462][    T7]  brcmf_notify_connect_status+0x448/0x1950
[   46.622134][    T7]  ? rcu_read_lock_bh_held+0xb0/0xb0
[   46.622736][    T7]  ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0
[   46.623390][    T7]  ? find_held_lock+0x2d/0x110
[   46.623962][    T7]  ? brcmf_fweh_event_worker+0x19f/0xc60
[   46.624603][    T7]  ? mark_held_locks+0x9f/0xe0
[   46.625145][    T7]  ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
[   46.625871][    T7]  ? brcmf_cfg80211_join_ibss+0x7b0/0x7b0
[   46.626545][    T7]  brcmf_fweh_call_event_handler.isra.0+0x90/0x100
[   46.627338][    T7]  brcmf_fweh_event_worker+0x557/0xc60
[   46.627962][    T7]  ? brcmf_fweh_call_event_handler.isra.0+0x100/0x100
[   46.628736][    T7]  ? rcu_read_lock_sched_held+0xa1/0xd0
[   46.629396][    T7]  ? rcu_read_lock_bh_held+0xb0/0xb0
[   46.629970][    T7]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[   46.630649][    T7]  process_one_work+0x92b/0x1460
[   46.631205][    T7]  ? pwq_dec_nr_in_flight+0x330/0x330
[   46.631821][    T7]  ? rwlock_bug.part.0+0x90/0x90
[   46.632347][    T7]  worker_thread+0x95/0xe00
[   46.632832][    T7]  ? __kthread_parkme+0x115/0x1e0
[   46.633393][    T7]  ? process_one_work+0x1460/0x1460
[   46.633957][    T7]  kthread+0x3a1/0x480
[   46.634369][    T7]  ? set_kthread_struct+0x120/0x120
[   46.634933][    T7]  ret_from_fork+0x1f/0x30
[   46.635431][    T7]
[   46.635687][    T7] Allocated by task 7:
[   46.636151][    T7]  kasan_save_stack+0x1b/0x40
[   46.636628][    T7]  __kasan_kmalloc+0x7c/0x90
[   46.637108][    T7]  kmem_cache_alloc_trace+0x19e/0x330
[   46.637696][    T7]  brcmf_cfg80211_attach+0x4a0/0x4040
[   46.638275][    T7]  brcmf_attach+0x389/0xd40
[   46.638739][    T7]  brcmf_usb_probe+0x12de/0x1690
[   46.639279][    T7]  usb_probe_interface+0x2aa/0x760
[   46.639820][    T7]  really_probe+0x205/0xb70
[   46.640342][    T7]  __driver_probe_device+0x311/0x4b0
[   46.640876][    T7]  driver_probe_device+0x4e/0x150
[   46.641445][    T7]  __device_attach_driver+0x1cc/0x2a0
[   46.642000][    T7]  bus_for_each_drv+0x156/0x1d0
[   46.642543][    T7]  __device_attach+0x23f/0x3a0
[   46.643065][    T7]  bus_probe_device+0x1da/0x290
[   46.643644][    T7]  device_add+0xb7b/0x1eb0
[   46.644130][    T7]  usb_set_configuration+0xf59/0x16f0
[   46.644720][    T7]  usb_generic_driver_probe+0x82/0xa0
[   46.645295][    T7]  usb_probe_device+0xbb/0x250
[   46.645786][    T7]  really_probe+0x205/0xb70
[   46.646258][    T7]  __driver_probe_device+0x311/0x4b0
[   46.646804][    T7]  driver_probe_device+0x4e/0x150
[   46.647387][    T7]  __device_attach_driver+0x1cc/0x2a0
[   46.647926][    T7]  bus_for_each_drv+0x156/0x1d0
[   46.648454][    T7]  __device_attach+0x23f/0x3a0
[   46.648939][    T7]  bus_probe_device+0x1da/0x290
[   46.649478][    T7]  device_add+0xb7b/0x1eb0
[   46.649936][    T7]  usb_new_device.cold+0x49c/0x1029
[   46.650526][    T7]  hub_event+0x1c98/0x3950
[   46.650975][    T7]  process_one_work+0x92b/0x1460
[   46.651535][    T7]  worker_thread+0x95/0xe00
[   46.651991][    T7]  kthread+0x3a1/0x480
[   46.652413][    T7]  ret_from_fork+0x1f/0x30
[   46.652885][    T7]
[   46.653131][    T7] The buggy address belongs to the object at ffff888019442000
[   46.653131][    T7]  which belongs to the cache kmalloc-2k of size 2048
[   46.654669][    T7] The buggy address is located 0 bytes inside of
[   46.654669][    T7]  2048-byte region [ffff888019442000, ffff888019442800)
[   46.656137][    T7] The buggy address belongs to the page:
[   46.656720][    T7] page:ffffea0000651000 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x19440
[   46.657792][    T7] head:ffffea0000651000 order:3 compound_mapcount:0 compound_pincount:0
[   46.658673][    T7] flags: 0x100000000010200(slab|head|node=0|zone=1)
[   46.659422][    T7] raw: 0100000000010200 0000000000000000 dead000000000122 ffff888100042000
[   46.660363][    T7] raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000
[   46.661236][    T7] page dumped because: kasan: bad access detected
[   46.661956][    T7] page_owner tracks the page as allocated
[   46.662588][    T7] page last allocated via order 3, migratetype Unmovable, gfp_mask 0x52a20(GFP_ATOMIC|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP), pid 7, ts 31136961085, free_ts 0
[   46.664271][    T7]  prep_new_page+0x1aa/0x240
[   46.664763][    T7]  get_page_from_freelist+0x159a/0x27c0
[   46.665340][    T7]  __alloc_pages+0x2da/0x6a0
[   46.665847][    T7]  alloc_pages+0xec/0x1e0
[   46.666308][    T7]  allocate_slab+0x380/0x4e0
[   46.666770][    T7]  ___slab_alloc+0x5bc/0x940
[   46.667264][    T7]  __slab_alloc+0x6d/0x80
[   46.667712][    T7]  kmem_cache_alloc_trace+0x30a/0x330
[   46.668299][    T7]  brcmf_usbdev_qinit.constprop.0+0x50/0x470
[   46.668885][    T7]  brcmf_usb_probe+0xc97/0x1690
[   46.669438][    T7]  usb_probe_interface+0x2aa/0x760
[   46.669988][    T7]  really_probe+0x205/0xb70
[   46.670487][    T7]  __driver_probe_device+0x311/0x4b0
[   46.671031][    T7]  driver_probe_device+0x4e/0x150
[   46.671604][    T7]  __device_attach_driver+0x1cc/0x2a0
[   46.672192][    T7]  bus_for_each_drv+0x156/0x1d0
[   46.672739][    T7] page_owner free stack trace missing
[   46.673335][    T7]
[   46.673620][    T7] Memory state around the buggy address:
[   46.674213][    T7]  ffff888019442700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   46.675083][    T7]  ffff888019442780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   46.675994][    T7] >ffff888019442800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   46.676875][    T7]                    ^
[   46.677323][    T7]  ffff888019442880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   46.678190][    T7]  ffff888019442900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   46.679052][    T7] ==================================================================
[   46.679945][    T7] Disabling lock debugging due to kernel taint
[   46.680725][    T7] Kernel panic - not syncing:
Reviewed-by: NArend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: NJisoo Jang <jisoo.jang@yonsei.ac.kr>
Signed-off-by: NKalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20230309104457.22628-1-jisoo.jang@yonsei.ac.krSigned-off-by: NBaisong Zhong <zhongbaisong@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      8a2a4e91
    • J
      arm64: errata: Remove AES hwcap for COMPAT tasks · 2e5dfa80
      由 James Morse 提交于 
      stable inclusion
from stable-v5.10.152
commit 51b96ecaedc0a12f6827f189a94f59012dde8208
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6O293

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

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

commit 44b3834b upstream.

Cortex-A57 and Cortex-A72 have an erratum where an interrupt that
occurs between a pair of AES instructions in aarch32 mode may corrupt
the ELR. The task will subsequently produce the wrong AES result.

The AES instructions are part of the cryptographic extensions, which are
optional. User-space software will detect the support for these
instructions from the hwcaps. If the platform doesn't support these
instructions a software implementation should be used.

Remove the hwcap bits on affected parts to indicate user-space should
not use the AES instructions.
Acked-by: NArd Biesheuvel <ardb@kernel.org>
Signed-off-by: NJames Morse <james.morse@arm.com>
Link: https://lore.kernel.org/r/20220714161523.279570-3-james.morse@arm.comSigned-off-by: NWill Deacon <will@kernel.org>
[florian: removed arch/arm64/tools/cpucaps and fixup cpufeature.c]
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

conflicts:
    arch/arm64/Kconfig
    rch/arm64/include/asm/cpucaps.h
    rch/arm64/kernel/cpu_errata.c
    rch/arm64/kernel/cpufeature.c
Signed-off-by: NLin Yujun <linyujun809@huawei.com>
Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
      2e5dfa80