提交 · 3fbf32b8a2d7ca6679c1f8ff8584162045910689 · openeuler / Kernel

28 4月, 2023 8 次提交

mm: mem_reliable: Use zone_page_state to count free reliable pages · 3fbf32b8

由 Ma Wupeng 提交于 4月 28, 2023

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6RKHX
CVE: NA

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

commit ee97b610 ("mm: Count mirrored pages in buddy system") proposes
to use vmstat events (PGALLOC/PGFREE) to count free reliable pages.
However, this can be achieved by counting NR_FREE_PAGES for all
non-movable zones, which will have better compatibility. Therefore, replace
it.
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

3fbf32b8

writeback, cgroup: fix null-ptr-deref write in bdi_split_work_to_wbs · 641e7fcc

由 Baokun Li 提交于 4月 28, 2023

mainline inclusion
from mainline-v6.3-rc8
commit 1ba1199e
category: bugfix
bugzilla: 188601, https://gitee.com/openeuler/kernel/issues/I6TNTC
CVE: NA

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

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

KASAN report null-ptr-deref:
==================================================================
BUG: KASAN: null-ptr-deref in bdi_split_work_to_wbs+0x5c5/0x7b0
Write of size 8 at addr 0000000000000000 by task sync/943
CPU: 5 PID: 943 Comm: sync Tainted: 6.3.0-rc5-next-20230406-dirty #461
Call Trace:
 <TASK>
 dump_stack_lvl+0x7f/0xc0
 print_report+0x2ba/0x340
 kasan_report+0xc4/0x120
 kasan_check_range+0x1b7/0x2e0
 __kasan_check_write+0x24/0x40
 bdi_split_work_to_wbs+0x5c5/0x7b0
 sync_inodes_sb+0x195/0x630
 sync_inodes_one_sb+0x3a/0x50
 iterate_supers+0x106/0x1b0
 ksys_sync+0x98/0x160
[...]
==================================================================

The race that causes the above issue is as follows:

           cpu1                     cpu2
-------------------------|-------------------------
inode_switch_wbs
 INIT_WORK(&isw->work, inode_switch_wbs_work_fn)
 queue_rcu_work(isw_wq, &isw->work)
 // queue_work async
  inode_switch_wbs_work_fn
   wb_put_many(old_wb, nr_switched)
    percpu_ref_put_many
     ref->data->release(ref)
     cgwb_release
      queue_work(cgwb_release_wq, &wb->release_work)
      // queue_work async
       &wb->release_work
       cgwb_release_workfn
                            ksys_sync
                             iterate_supers
                              sync_inodes_one_sb
                               sync_inodes_sb
                                bdi_split_work_to_wbs
                                 kmalloc(sizeof(*work), GFP_ATOMIC)
                                 // alloc memory failed
        percpu_ref_exit
         ref->data = NULL
         kfree(data)
                                 wb_get(wb)
                                  percpu_ref_get(&wb->refcnt)
                                   percpu_ref_get_many(ref, 1)
                                    atomic_long_add(nr, &ref->data->count)
                                     atomic64_add(i, v)
                                     // trigger null-ptr-deref

bdi_split_work_to_wbs() traverses &bdi->wb_list to split work into all
wbs.  If the allocation of new work fails, the on-stack fallback will be
used and the reference count of the current wb is increased afterwards.
If cgroup writeback membership switches occur before getting the reference
count and the current wb is released as old_wd, then calling wb_get() or
wb_put() will trigger the null pointer dereference above.

This issue was introduced in v4.3-rc7 (see fix tag1).  Both
sync_inodes_sb() and __writeback_inodes_sb_nr() calls to
bdi_split_work_to_wbs() can trigger this issue.  For scenarios called via
sync_inodes_sb(), originally commit 7fc5854f ("writeback: synchronize
sync(2) against cgroup writeback membership switches") reduced the
possibility of the issue by adding wb_switch_rwsem, but in v5.14-rc1 (see
fix tag2) removed the "inode_io_list_del_locked(inode, old_wb)" from
inode_switch_wbs_work_fn() so that wb->state contains WB_has_dirty_io,
thus old_wb is not skipped when traversing wbs in bdi_split_work_to_wbs(),
and the issue becomes easily reproducible again.

To solve this problem, percpu_ref_exit() is called under RCU protection to
avoid race between cgwb_release_workfn() and bdi_split_work_to_wbs().
Moreover, replace wb_get() with wb_tryget() in bdi_split_work_to_wbs(),
and skip the current wb if wb_tryget() fails because the wb has already
been shutdown.

Link: https://lkml.kernel.org/r/20230410130826.1492525-1-libaokun1@huawei.com
Fixes: b817525a ("writeback: bdi_writeback iteration must not skip dying ones")
Signed-off-by: NBaokun Li <libaokun1@huawei.com>
Reviewed-by: NJan Kara <jack@suse.cz>
Acked-by: NTejun Heo <tj@kernel.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Hou Tao <houtao1@huawei.com>
Cc: yangerkun <yangerkun@huawei.com>
Cc: Zhang Yi <yi.zhang@huawei.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

Conflicts:
	mm/backing-dev.c
Signed-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: NYongqiang Liu <liuyongqiang13@huawei.com>

641e7fcc

sctp: leave the err path free in sctp_stream_init to sctp_stream_free · 703397c7

由 Xin Long 提交于 4月 28, 2023

mainline inclusion
from mainline-v5.19-rc7
commit 181d8d20
category: bugfix
bugzilla: 188712,https://gitee.com/src-openeuler/kernel/issues/I6X47E
CVE: CVE-2023-2177

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

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

A NULL pointer dereference was reported by Wei Chen:

  BUG: kernel NULL pointer dereference, address: 0000000000000000
  RIP: 0010:__list_del_entry_valid+0x26/0x80
  Call Trace:
   <TASK>
   sctp_sched_dequeue_common+0x1c/0x90
   sctp_sched_prio_dequeue+0x67/0x80
   __sctp_outq_teardown+0x299/0x380
   sctp_outq_free+0x15/0x20
   sctp_association_free+0xc3/0x440
   sctp_do_sm+0x1ca7/0x2210
   sctp_assoc_bh_rcv+0x1f6/0x340

This happens when calling sctp_sendmsg without connecting to server first.
In this case, a data chunk already queues up in send queue of client side
when processing the INIT_ACK from server in sctp_process_init() where it
calls sctp_stream_init() to alloc stream_in. If it fails to alloc stream_in
all stream_out will be freed in sctp_stream_init's err path. Then in the
asoc freeing it will crash when dequeuing this data chunk as stream_out
is missing.

As we can't free stream out before dequeuing all data from send queue, and
this patch is to fix it by moving the err path stream_out/in freeing in
sctp_stream_init() to sctp_stream_free() which is eventually called when
freeing the asoc in sctp_association_free(). This fix also makes the code
in sctp_process_init() more clear.

Note that in sctp_association_init() when it fails in sctp_stream_init(),
sctp_association_free() will not be called, and in that case it should
go to 'stream_free' err path to free stream instead of 'fail_init'.

Fixes: 5bbbbe32 ("sctp: introduce stream scheduler foundations")
Reported-by: NWei Chen <harperchen1110@gmail.com>
Signed-off-by: NXin Long <lucien.xin@gmail.com>
Link: https://lore.kernel.org/r/831a3dc100c4908ff76e5bcc363be97f2778bc0b.1658787066.git.lucien.xin@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Conflicts:
	net/sctp/stream.c
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

703397c7

RDMA/core: Refactor rdma_bind_addr · 5ca384e3

由 Patrisious Haddad 提交于 4月 28, 2023

mainline inclusion
from mainline-v6.3-rc1
commit 8d037973
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6X49E
CVE: CVE-2023-2176

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

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

Refactor rdma_bind_addr function so that it doesn't require that the
cma destination address be changed before calling it.

So now it will update the destination address internally only when it is
really needed and after passing all the required checks.

Which in turn results in a cleaner and more sensible call and error
handling flows for the functions that call it directly or indirectly.
Signed-off-by: NPatrisious Haddad <phaddad@nvidia.com>
Reported-by: NWei Chen <harperchen1110@gmail.com>
Reviewed-by: NMark Zhang <markzhang@nvidia.com>
Link: https://lore.kernel.org/r/3d0e9a2fd62bc10ba02fed1c7c48a48638952320.1672819273.git.leonro@nvidia.comSigned-off-by: NLeon Romanovsky <leon@kernel.org>
(cherry picked from commit 8d037973)
Signed-off-by: NLiu Jian <liujian56@huawei.com>

Conflicts:
	drivers/infiniband/core/cma.c
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

5ca384e3

Revert "RDMA/cma: Simplify rdma_resolve_addr() error flow" · be16dfab

由 Parav Pandit 提交于 4月 28, 2023

mainline inclusion
from mainline-v5.6-rc5
commit e4103312
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6X49E
CVE: CVE-2023-2176

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

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

This reverts commit 219d2e9d.

The call chain below requires the cm_id_priv's destination address to be
setup before performing rdma_bind_addr(). Otherwise source port allocation
fails as cma_port_is_unique() no longer sees the correct tuple to allow
duplicate users of the source port.

rdma_resolve_addr()
  cma_bind_addr()
    rdma_bind_addr()
      cma_get_port()
        cma_alloc_any_port()
          cma_port_is_unique() <- compared with zero daddr

This can result in false failures to connect, particularly if the source
port range is restricted.

Fixes: 219d2e9d ("RDMA/cma: Simplify rdma_resolve_addr() error flow")
Link: https://lore.kernel.org/r/20200212072635.682689-4-leon@kernel.orgSigned-off-by: NParav Pandit <parav@mellanox.com>
Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
(cherry picked from commit e4103312)
Signed-off-by: NLiu Jian <liujian56@huawei.com>

Conflicts:
	drivers/infiniband/core/cma.c
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

be16dfab

fix kabi broken due to import new inode operation get_inode_acl · c309468e

由 Zhihao Cheng 提交于 4月 28, 2023

hulk inclusion
category: perf
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ZCW0
CVE: NA

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

Fix kabi broken for importing new inode operation get_inode_acl.
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NJialin Zhang <zhangjialin11@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

c309468e

ovl: enable RCU'd ->get_acl() · e01a5e43

由 Miklos Szeredi 提交于 4月 28, 2023

mainline inclusion
from mainline-v5.15-rc1
commit 332f606b
category: perf
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ZCW0
CVE: NA

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

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

Overlayfs does not cache ACL's (to avoid double caching).  Instead it just
calls the underlying filesystem's i_op->get_acl(), which will return the
cached value, if possible.

In rcu path walk, however, get_cached_acl_rcu() is employed to get the
value from the cache, which will fail on overlayfs resulting in dropping
out of rcu walk mode.  This can result in a big performance hit in certain
situations.

Fix by calling ->get_acl() with rcu=true in case of ACL_DONT_CACHE (which
indicates pass-through)
Reported-by: Ngaryhuang <zjh.20052005@163.com>
Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
Conflicts:
	fs/posix_acl.c
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

e01a5e43

vfs: add rcu argument to ->get_acl() callback · 527b26b1

由 Miklos Szeredi 提交于 4月 28, 2023

mainline inclusion
from mainline-v5.15-rc1
commit 0cad6246
category: perf
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ZCW0
CVE: NA

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

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

Add a rcu argument to the ->get_acl() callback to allow
get_cached_acl_rcu() to call the ->get_acl() method in the next patch.
Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
[chengzhihao: rename get_acl to get_acl2 to prevent KABI changes, and
 only backport(realize) overlayfs]
Conflicts:
	fs/overlayfs/dir.c
	fs/overlayfs/inode.c
	fs/overlayfs/overlayfs.h
	fs/posix_acl.c
	include/linux/fs.h
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

527b26b1

26 4月, 2023 1 次提交

RDMA/hns: Add check for user-configured max_inline_data value · 18f1f202

由 zhaoweibo 提交于 4月 26, 2023

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I51UWX
CVE: NA

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

When the user-configured max_inline_data value exceeds the hardware
specification, an err needs to be returned.

Fixes: 87d3b87b ("RDMA/hns: Optimize qp param setup flow")
Signed-off-by: Nzhaoweibo <zhaoweibo3@huawei.com>
Reviewed-by: NChunzhi Hu <huchunzhi@huawei.com>
Signed-off-by: NZhang Changzhong <zhangchangzhong@huawei.com>

18f1f202

25 4月, 2023 1 次提交

power: supply: da9150: Fix use after free bug in da9150_charger_remove due to race condition · 5f77c283

由 Zheng Wang 提交于 4月 25, 2023

stable inclusion
from stable-v4.19.280
commit 533d915899b4a5a7b5b5a99eec24b2920ccd1f11
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6W80A
CVE: CVE-2023-30772

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

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

[ Upstream commit 06615d11 ]

In da9150_charger_probe, &charger->otg_work is bound with
da9150_charger_otg_work. da9150_charger_otg_ncb may be
called to start the work.

If we remove the module which will call da9150_charger_remove
to make cleanup, there may be a unfinished work. The possible
sequence is as follows:

Fix it by canceling the work before cleanup in the da9150_charger_remove

CPU0                  CPUc1

                    |da9150_charger_otg_work
da9150_charger_remove      |
power_supply_unregister  |
device_unregister   |
power_supply_dev_release|
kfree(psy)          |
                    |
                    | 	power_supply_changed(charger->usb);
                    |   //use

Fixes: c1a281e3 ("power: Add support for DA9150 Charger")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

5f77c283

24 4月, 2023 1 次提交

!430 [openEuler-1.0-LTS] ata: sata_zhaoxin: Update Zhaoxin Serial ATA product name · 25717315

由 openeuler-ci-bot 提交于 4月 24, 2023

Merge Pull Request from: @leoliu-oc 
 
Change internal project name to external product name.

### Issue
https://gitee.com/openeuler/kernel/issues/I6J0SW

### Test
N/A

### Knowe Issue
N/A

### Default config change
N/A 
 
Link:https://gitee.com/openeuler/kernel/pulls/430 

Reviewed-by: Wei Li <liwei391@huawei.com>

25717315

23 4月, 2023 3 次提交

i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer() · b735f669

由 Wei Chen 提交于 4月 23, 2023

mainline inclusion
from mainline-v6.3-rc4
commit 92fbb6d1
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6XHPL
CVE: CVE-2023-2194

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

The data->block[0] variable comes from user and is a number between
0-255. Without proper check, the variable may be very large to cause
an out-of-bounds when performing memcpy in slimpro_i2c_blkwr.

Fix this bug by checking the value of writelen.

Fixes: f6505fba ("i2c: add SLIMpro I2C device driver on APM X-Gene platform")
Signed-off-by: NWei Chen <harperchen1110@gmail.com>
Cc: stable@vger.kernel.org
Reviewed-by: NAndi Shyti <andi.shyti@kernel.org>
Signed-off-by: NWolfram Sang <wsa@kernel.org>
Signed-off-by: NYang Jihong <yangjihong1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

b735f669

audit: fix a memleak caused by auditing load module · 08551f22

由 Li RongQing 提交于 4月 23, 2023

mainline inclusion
from mainline-v5.2-rc1
commit 95e0b46f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6X2LV
CVE: NA

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

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

module.name will be allocated unconditionally when auditing load
module, and audit_log_start() can fail with other reasons, or
audit_log_exit maybe not called, caused module.name is not freed

so free module.name in audit_free_context and __audit_syscall_exit

unreferenced object 0xffff88af90837d20 (size 8):
  comm "modprobe", pid 1036, jiffies 4294704867 (age 3069.138s)
  hex dump (first 8 bytes):
    69 78 67 62 65 00 ff ff                          ixgbe...
  backtrace:
    [<0000000008da28fe>] __audit_log_kern_module+0x33/0x80
    [<00000000c1491e61>] load_module+0x64f/0x3850
    [<000000007fc9ae3f>] __do_sys_init_module+0x218/0x250
    [<0000000000d4a478>] do_syscall_64+0x117/0x400
    [<000000004924ded8>] entry_SYSCALL_64_after_hwframe+0x49/0xbe
    [<000000007dc331dd>] 0xffffffffffffffff

Fixes: ca86cad7 ("audit: log module name on init_module")
Signed-off-by: NZhang Yu <zhangyu31@baidu.com>
Signed-off-by: NLi RongQing <lirongqing@baidu.com>
[PM: manual merge fixup in __audit_syscall_exit()]
Signed-off-by: NPaul Moore <paul@paul-moore.com>

conflict:
	kernel/auditsc.c
Signed-off-by: NYi Yang <yiyang13@huawei.com>
Reviewed-by: Ncuigaosheng <cuigaosheng1@huawei.com>
Reviewed-by: Nguozihua <guozihua@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

08551f22

!595 [openEuler-1.0-LTS] iommu/arm-smmu-v3: Fix UAF when handle evt during iommu group removing · 632f732c

由 openeuler-ci-bot 提交于 4月 23, 2023

Merge Pull Request from: @ch-cityhunter 
 
#### 设备remove流程和smmu中断处理线程是异步的，并发情况下有UAF问题

1. arm_smmu_remove_device流程先释放了dev->iommu_param
   中断线程查找的红黑树还能找到对应master，会导致UAF
2. 中断线程通过红黑树获取master之后使用的过程没有保护
   remove流程也可以在其查找成功之后释放dev->iommu_param

openeuler在2019年最初上库第一版arm-smmu-v3是就有此问题

#### 修改方法

参考内核社区，arm-smmu-v3在2021年合入社区，此问题经过review后已修正，首次合入是没问题的
https://github.com/torvalds/linux/commit/395ad89d11fd93f79a6b942e91fc409807a63c4b

1. 调整移除master和释放内存的顺序，先移除master，避免被其他流程查找到
2. arm_smmu_find_master()外部加锁，保护中断线程获取master后整个使用阶段

```
driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6WKM7
CVE: NA

--------

A use-after-free issue like following:

[ 2257.819189] arm-smmu-v3 arm-smmu-v3.4.auto: EVTQ overflow detected -- events lost
[ 2257.819197] arm-smmu-v3 arm-smmu-v3.4.auto: event 0x10 received:
[ 2257.819199] arm-smmu-v3 arm-smmu-v3.4.auto:  0x0000820000000010
[ 2257.819201] arm-smmu-v3 arm-smmu-v3.4.auto:  0x0000020000000000
[ 2257.819202] arm-smmu-v3 arm-smmu-v3.4.auto:  0x00000000dfea7218
[ 2257.819206] iommu: Removing device 0000:82:00.0 from group 49
[ 2257.819207] arm-smmu-v3 arm-smmu-v3.4.auto:  0x00000000dfea7000
[ 2257.819211] arm-smmu-v3 arm-smmu-v3.4.auto: event 0x10 received:
[ 2257.819212] arm-smmu-v3 arm-smmu-v3.4.auto:  0x0000820000000010
[ 2257.819214] arm-smmu-v3 arm-smmu-v3.4.auto:  0x0000020000000000
[ 2257.819215] arm-smmu-v3 arm-smmu-v3.4.auto:  0x00000000dfea722c
[ 2257.819216] arm-smmu-v3 arm-smmu-v3.4.auto:  0x00000000dfea7000
[ 2257.819218] ==================================================================
[ 2257.819228] BUG: KASAN: use-after-free in iommu_report_device_fault+0x520/0x5c0
[ 2257.819230] Read of size 8 at addr ffffa02c516c1320 by task irq/63-arm-smmu/483
[ 2257.819231]
[ 2257.819235] CPU: 25 PID: 483 Comm: irq/63-arm-smmu Kdump: loaded Tainted: G           OE     4.19.90-2205.3.0.0149.oe1.aarch64+debug #1
[ 2257.819236] Hardware name: Huawei S920S00/BC82AMDGK, BIOS 1.68 11/10/2020
[ 2257.819237] Call trace:
[ 2257.819240]  dump_backtrace+0x0/0x320
[ 2257.819242]  show_stack+0x24/0x30
[ 2257.819246]  dump_stack+0xdc/0x128
[ 2257.819251]  print_address_description+0x68/0x278
[ 2257.819253]  kasan_report+0x1e4/0x308
[ 2257.819254]  __asan_report_load8_noabort+0x30/0x40
[ 2257.819257]  iommu_report_device_fault+0x520/0x5c0
[ 2257.819260]  arm_smmu_handle_evt+0x300/0x428
[ 2257.819261]  arm_smmu_evtq_thread+0x27c/0x460
[ 2257.819264]  irq_thread_fn+0x88/0x140
[ 2257.819266]  irq_thread+0x190/0x318
[ 2257.819268]  kthread+0x2a4/0x320
[ 2257.819270]  ret_from_fork+0x10/0x18
[ 2257.819271]
[ 2257.819273] Allocated by task 95166:
[ 2257.819275]  kasan_kmalloc+0xd0/0x178
[ 2257.819277]  kmem_cache_alloc_trace+0x100/0x210
[ 2257.819279]  iommu_group_add_device+0x254/0xe18
[ 2257.819280]  iommu_group_get_for_dev+0x198/0x480
[ 2257.819282]  arm_smmu_add_device+0x424/0x988
[ 2257.819284]  iort_iommu_configure+0x33c/0x5b8
[ 2257.819287]  acpi_dma_configure+0x9c/0xf8
[ 2257.819289]  pci_dma_configure+0x124/0x158
[ 2257.819291]  dma_configure+0x5c/0x80
[ 2257.819294]  really_probe+0xcc/0x920
[ 2257.819296]  driver_probe_device+0x224/0x308
[ 2257.819298]  __device_attach_driver+0x154/0x260
[ 2257.819299]  bus_for_each_drv+0xe4/0x178
[ 2257.819301]  __device_attach+0x1bc/0x2a8
[ 2257.819302]  device_attach+0x24/0x30
[ 2257.819304]  pci_bus_add_device+0x7c/0xe8
[ 2257.819305]  pci_bus_add_devices+0x70/0x168
[ 2257.819307]  pci_bus_add_devices+0x114/0x168
[ 2257.819308]  pci_rescan_bus+0x38/0x48
[ 2257.819310]  bus_rescan_store+0xc4/0xe8
[ 2257.819312]  bus_attr_store+0x70/0x98
[ 2257.819314]  sysfs_kf_write+0x104/0x170
[ 2257.819316]  kernfs_fop_write+0x23c/0x430
[ 2257.819319]  __vfs_write+0x7c/0xe8
[ 2257.819320]  vfs_write+0x12c/0x3d0
[ 2257.819321]  ksys_write+0xd4/0x1d8
[ 2257.819322]  __arm64_sys_write+0x70/0xa0
[ 2257.819325]  el0_svc_common+0xfc/0x278
[ 2257.819327]  el0_svc_handler+0x50/0xc0
[ 2257.819329]  el0_svc+0x8/0x1b0
[ 2257.819329]
[ 2257.819330] Freed by task 95166:
[ 2257.819332]  __kasan_slab_free+0x114/0x200
[ 2257.819334]  kasan_slab_free+0x10/0x18
[ 2257.819335]  kfree+0x80/0x1f0
[ 2257.819337]  iommu_group_remove_device+0x27c/0x560
[ 2257.819338]  arm_smmu_remove_device+0xe8/0x190
[ 2257.819339]  iommu_bus_notifier+0x134/0x248
[ 2257.819342]  notifier_call_chain+0xb0/0x140
[ 2257.819343]  blocking_notifier_call_chain+0x6c/0xd8
[ 2257.819344]  device_del+0x578/0x940
[ 2257.819346]  pci_remove_bus_device+0x114/0x290
[ 2257.819347]  pci_stop_and_remove_bus_device_locked+0x2c/0x40
[ 2257.819349]  remove_store+0xdc/0xe8
[ 2257.819352]  dev_attr_store+0x60/0x80
[ 2257.819353]  sysfs_kf_write+0x104/0x170
[ 2257.819354]  kernfs_fop_write+0x23c/0x430
[ 2257.819355]  __vfs_write+0x7c/0xe8
[ 2257.819357]  vfs_write+0x12c/0x3d0
[ 2257.819358]  ksys_write+0xd4/0x1d8
[ 2257.819359]  __arm64_sys_write+0x70/0xa0
[ 2257.819361]  el0_svc_common+0xfc/0x278
[ 2257.819362]  el0_svc_handler+0x50/0xc0
[ 2257.819364]  el0_svc+0x8/0x1b0
[ 2257.819364]

           T0                                 T1
---------------------------------    ---------------------------------
|- arm_smmu_evtq_thread              |- arm_smmu_remove_device
  |- arm_smmu_handle_evt               |- iommu_group_remove_device
                                         |- kfree(dev->iommu_param)
    |- arm_smmu_find_master
    |- iommu_report_device_fault       |- arm_smmu_remove_master
      |- mutex_lock( \
         &dev->iommu_param->lock)
         // UAF

Reference upstream mainline commit 395ad89d,
move arm_smmu_remove_master() before iommu_group_remove_device(),
and hold mutex to protect finding master and subsequent handling.
``` 
 
Link:https://gitee.com/openeuler/kernel/pulls/595 

Reviewed-by: Weilong Chen <chenweilong@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>

632f732c

19 4月, 2023 2 次提交

tcp: restrict net.ipv4.tcp_app_win · 091ae3d5

由 YueHaibing 提交于 4月 19, 2023

mainline inclusion
from mainline-v6.3-rc7
commit dc5110c2
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6WB6P
CVE: NA

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

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

UBSAN: shift-out-of-bounds in net/ipv4/tcp_input.c:555:23
shift exponent 255 is too large for 32-bit type 'int'
CPU: 1 PID: 7907 Comm: ssh Not tainted 6.3.0-rc4-00161-g62bad54b-dirty #206
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x136/0x150
 __ubsan_handle_shift_out_of_bounds+0x21f/0x5a0
 tcp_init_transfer.cold+0x3a/0xb9
 tcp_finish_connect+0x1d0/0x620
 tcp_rcv_state_process+0xd78/0x4d60
 tcp_v4_do_rcv+0x33d/0x9d0
 __release_sock+0x133/0x3b0
 release_sock+0x58/0x1b0

'maxwin' is int, shifting int for 32 or more bits is undefined behaviour.

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Reviewed-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

091ae3d5

x86/speculation: Allow enabling STIBP with legacy IBRS · 21f0fb9d

由 KP Singh 提交于 4月 19, 2023

stable inclusion
from stable-v4.19.276
commit 10543fb3c9b019e45e2045f08f46fdf526add593
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6V7TU
CVE: CVE-2023-1998

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

commit 6921ed90 upstream.

When plain IBRS is enabled (not enhanced IBRS), the logic in
spectre_v2_user_select_mitigation() determines that STIBP is not needed.

The IBRS bit implicitly protects against cross-thread branch target
injection. However, with legacy IBRS, the IBRS bit is cleared on
returning to userspace for performance reasons which leaves userspace
threads vulnerable to cross-thread branch target injection against which
STIBP protects.

Exclude IBRS from the spectre_v2_in_ibrs_mode() check to allow for
enabling STIBP (through seccomp/prctl() by default or always-on, if
selected by spectre_v2_user kernel cmdline parameter).

  [ bp: Massage. ]

Fixes: 7c693f54 ("x86/speculation: Add spectre_v2=ibrs option to support Kernel IBRS")
Reported-by: NJosé Oliveira <joseloliveira11@gmail.com>
Reported-by: NRodrigo Branco <rodrigo@kernelhacking.com>
Signed-off-by: NKP Singh <kpsingh@kernel.org>
Signed-off-by: NBorislav Petkov (AMD) <bp@alien8.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20230220120127.1975241-1-kpsingh@kernel.org
Link: https://lore.kernel.org/r/20230221184908.2349578-1-kpsingh@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

21f0fb9d

18 4月, 2023 9 次提交

KVM: nVMX: add missing consistency checks for CR0 and CR4 · 3987c836

由 Paolo Bonzini 提交于 4月 18, 2023

stable inclusion
from stable-v5.10.176
commit c54974ccaff73525462e278602dfe4069877cfaa
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6U7AN
CVE: CVE-2023-30456

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

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

commit 112e6601 upstream.

The effective values of the guest CR0 and CR4 registers may differ from
those included in the VMCS12.  In particular, disabling EPT forces
CR4.PAE=1 and disabling unrestricted guest mode forces CR0.PG=CR0.PE=1.

Therefore, checks on these bits cannot be delegated to the processor
and must be performed by KVM.
Reported-by: NReima ISHII <ishiir@g.ecc.u-tokyo.ac.jp>
Cc: stable@vger.kernel.org
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

conflicts:
	arch/x86/kvm/vmx.c
Signed-off-by: NLin Yujun <linyujun809@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

3987c836

drm/vmwgfx: Validate the box size for the snooped cursor · 5e4437d3

由 Zack Rusin 提交于 4月 18, 2023

stable inclusion
from stable-v4.19.270
commit 6b4e70a428b5a11f56db94047b68e144529fe512
category: bugfix
bugzilla: 188685, https://gitee.com/src-openeuler/kernel/issues/I5QLC4
CVE：CVE-2022-36280

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

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

commit 4cf949c7 upstream.

Invalid userspace dma surface copies could potentially overflow
the memcpy from the surface to the snooped image leading to crashes.
To fix it the dimensions of the copybox have to be validated
against the expected size of the snooped cursor.
Signed-off-by: NZack Rusin <zackr@vmware.com>
Fixes: 2ac86371 ("vmwgfx: Snoop DMA transfers with non-covering sizes")
Cc: <stable@vger.kernel.org> # v3.2+
Reviewed-by: NMichael Banack <banackm@vmware.com>
Reviewed-by: NMartin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221026031936.1004280-1-zack@kde.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYuyao Lin <linyuyao1@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

5e4437d3

net/sched: Retire tcindex classifier · 261ad491

由 Jamal Hadi Salim 提交于 4月 18, 2023

stable inclusion
from stable-v4.19.276
commit 01d0d2b8b4e3cf2110baba9371c0c3d04ad5c77b
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6UYBU
CVE: CVE-2023-1829

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

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

commit 8c710f75 upstream.

The tcindex classifier has served us well for about a quarter of a century
but has not been getting much TLC due to lack of known users. Most recently
it has become easy prey to syzkaller. For this reason, we are retiring it.
Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com>
Acked-by: NJiri Pirko <jiri@nvidia.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

261ad491

Documentation/hw-vuln: Fix rST warning · 7a79450e

由 Paolo Bonzini 提交于 4月 18, 2023

mainline inclusion
from mainline-v6.2
commit 971cecb9
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6FB6C
CVE: CVE-2022-27672

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

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

The following warning:

   Documentation/admin-guide/hw-vuln/cross-thread-rsb.rst:92: ERROR: Unexpected indentation.

was introduced by commit 493a2c2d.  Fix it by placing everything in
the same paragraph and also use a monospace font.

Fixes: 493a2c2d ("Documentation/hw-vuln: Add documentation for Cross-Thread Return Predictions")
Reported-by: Stephen Rothwell <sfr@canb@auug.org.au>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

7a79450e

Documentation/hw-vuln: Add documentation for Cross-Thread Return Predictions · 11012146

由 Tom Lendacky 提交于 4月 18, 2023

stable inclusion
from stable-v5.15.94
commit 17170acdc7c8b8585501bb443b4f196168ae9890
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6FB6C
CVE: CVE-2022-27672

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

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

commit 493a2c2d upstream.

Add the admin guide for the Cross-Thread Return Predictions vulnerability.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Message-Id: <60f9c0b4396956ce70499ae180cb548720b25c7e.1675956146.git.thomas.lendacky@amd.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

11012146

KVM: x86: Mitigate the cross-thread return address predictions bug · 4c403c8e

由 Tom Lendacky 提交于 4月 18, 2023

stable inclusion
from stable-v5.15.94
commit 5122e0e44363e3d837592b78bc04222b9d289868
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6FB6C
CVE: CVE-2022-27672

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

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

commit 6f0f2d5e upstream.

By default, KVM/SVM will intercept attempts by the guest to transition
out of C0. However, the KVM_CAP_X86_DISABLE_EXITS capability can be used
by a VMM to change this behavior. To mitigate the cross-thread return
address predictions bug (X86_BUG_SMT_RSB), a VMM must not be allowed to
override the default behavior to intercept C0 transitions.

Use a module parameter to control the mitigation on processors that are
vulnerable to X86_BUG_SMT_RSB. If the processor is vulnerable to the
X86_BUG_SMT_RSB bug and the module parameter is set to mitigate the bug,
KVM will not allow the disabling of the HLT, MWAIT and CSTATE exits.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Message-Id: <4019348b5e07148eb4d593380a5f6713b93c9a16.1675956146.git.thomas.lendacky@amd.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

4c403c8e

x86/speculation: Identify processors vulnerable to SMT RSB predictions · 944927af

由 Tom Lendacky 提交于 4月 18, 2023

stable inclusion
from stable-v5.15.94
commit 8f12dcab90e886d0169a9cd372a8bb35339cfc19
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6FB6C
CVE: CVE-2022-27672

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

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

commit be8de49b upstream.

Certain AMD processors are vulnerable to a cross-thread return address
predictions bug. When running in SMT mode and one of the sibling threads
transitions out of C0 state, the other sibling thread could use return
target predictions from the sibling thread that transitioned out of C0.

The Spectre v2 mitigations cover the Linux kernel, as it fills the RSB
when context switching to the idle thread. However, KVM allows a VMM to
prevent exiting guest mode when transitioning out of C0. A guest could
act maliciously in this situation, so create a new x86 BUG that can be
used to detect if the processor is vulnerable.
Reviewed-by: NBorislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Message-Id: <91cec885656ca1fcd4f0185ce403a53dd9edecb7.1675956146.git.thomas.lendacky@amd.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

944927af

cpu/SMT: create and export cpu_smt_possible() · 133b4638

由 Vitaly Kuznetsov 提交于 4月 18, 2023

mainline inclusion
from mainline-v5.4
commit e1572f1d
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6FB6C
CVE: CVE-2022-27672

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

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

KVM needs to know if SMT is theoretically possible, this means it is
supported and not forcefully disabled ('nosmt=force'). Create and
export cpu_smt_possible() answering this question.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

133b4638

iommu/arm-smmu-v3: Fix UAF when handle evt during iommu group removing · f7f16389

由 Ding Hui 提交于 4月 18, 2023

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6WKM7
CVE: NA

--------

A use-after-free issue like following:

[ 2257.819189] arm-smmu-v3 arm-smmu-v3.4.auto: EVTQ overflow detected -- events lost
[ 2257.819197] arm-smmu-v3 arm-smmu-v3.4.auto: event 0x10 received:
[ 2257.819199] arm-smmu-v3 arm-smmu-v3.4.auto:  0x0000820000000010
[ 2257.819201] arm-smmu-v3 arm-smmu-v3.4.auto:  0x0000020000000000
[ 2257.819202] arm-smmu-v3 arm-smmu-v3.4.auto:  0x00000000dfea7218
[ 2257.819206] iommu: Removing device 0000:82:00.0 from group 49
[ 2257.819207] arm-smmu-v3 arm-smmu-v3.4.auto:  0x00000000dfea7000
[ 2257.819211] arm-smmu-v3 arm-smmu-v3.4.auto: event 0x10 received:
[ 2257.819212] arm-smmu-v3 arm-smmu-v3.4.auto:  0x0000820000000010
[ 2257.819214] arm-smmu-v3 arm-smmu-v3.4.auto:  0x0000020000000000
[ 2257.819215] arm-smmu-v3 arm-smmu-v3.4.auto:  0x00000000dfea722c
[ 2257.819216] arm-smmu-v3 arm-smmu-v3.4.auto:  0x00000000dfea7000
[ 2257.819218] ==================================================================
[ 2257.819228] BUG: KASAN: use-after-free in iommu_report_device_fault+0x520/0x5c0
[ 2257.819230] Read of size 8 at addr ffffa02c516c1320 by task irq/63-arm-smmu/483
[ 2257.819231]
[ 2257.819235] CPU: 25 PID: 483 Comm: irq/63-arm-smmu Kdump: loaded Tainted: G           OE     4.19.90-2205.3.0.0149.oe1.aarch64+debug #1
[ 2257.819236] Hardware name: Huawei S920S00/BC82AMDGK, BIOS 1.68 11/10/2020
[ 2257.819237] Call trace:
[ 2257.819240]  dump_backtrace+0x0/0x320
[ 2257.819242]  show_stack+0x24/0x30
[ 2257.819246]  dump_stack+0xdc/0x128
[ 2257.819251]  print_address_description+0x68/0x278
[ 2257.819253]  kasan_report+0x1e4/0x308
[ 2257.819254]  __asan_report_load8_noabort+0x30/0x40
[ 2257.819257]  iommu_report_device_fault+0x520/0x5c0
[ 2257.819260]  arm_smmu_handle_evt+0x300/0x428
[ 2257.819261]  arm_smmu_evtq_thread+0x27c/0x460
[ 2257.819264]  irq_thread_fn+0x88/0x140
[ 2257.819266]  irq_thread+0x190/0x318
[ 2257.819268]  kthread+0x2a4/0x320
[ 2257.819270]  ret_from_fork+0x10/0x18
[ 2257.819271]
[ 2257.819273] Allocated by task 95166:
[ 2257.819275]  kasan_kmalloc+0xd0/0x178
[ 2257.819277]  kmem_cache_alloc_trace+0x100/0x210
[ 2257.819279]  iommu_group_add_device+0x254/0xe18
[ 2257.819280]  iommu_group_get_for_dev+0x198/0x480
[ 2257.819282]  arm_smmu_add_device+0x424/0x988
[ 2257.819284]  iort_iommu_configure+0x33c/0x5b8
[ 2257.819287]  acpi_dma_configure+0x9c/0xf8
[ 2257.819289]  pci_dma_configure+0x124/0x158
[ 2257.819291]  dma_configure+0x5c/0x80
[ 2257.819294]  really_probe+0xcc/0x920
[ 2257.819296]  driver_probe_device+0x224/0x308
[ 2257.819298]  __device_attach_driver+0x154/0x260
[ 2257.819299]  bus_for_each_drv+0xe4/0x178
[ 2257.819301]  __device_attach+0x1bc/0x2a8
[ 2257.819302]  device_attach+0x24/0x30
[ 2257.819304]  pci_bus_add_device+0x7c/0xe8
[ 2257.819305]  pci_bus_add_devices+0x70/0x168
[ 2257.819307]  pci_bus_add_devices+0x114/0x168
[ 2257.819308]  pci_rescan_bus+0x38/0x48
[ 2257.819310]  bus_rescan_store+0xc4/0xe8
[ 2257.819312]  bus_attr_store+0x70/0x98
[ 2257.819314]  sysfs_kf_write+0x104/0x170
[ 2257.819316]  kernfs_fop_write+0x23c/0x430
[ 2257.819319]  __vfs_write+0x7c/0xe8
[ 2257.819320]  vfs_write+0x12c/0x3d0
[ 2257.819321]  ksys_write+0xd4/0x1d8
[ 2257.819322]  __arm64_sys_write+0x70/0xa0
[ 2257.819325]  el0_svc_common+0xfc/0x278
[ 2257.819327]  el0_svc_handler+0x50/0xc0
[ 2257.819329]  el0_svc+0x8/0x1b0
[ 2257.819329]
[ 2257.819330] Freed by task 95166:
[ 2257.819332]  __kasan_slab_free+0x114/0x200
[ 2257.819334]  kasan_slab_free+0x10/0x18
[ 2257.819335]  kfree+0x80/0x1f0
[ 2257.819337]  iommu_group_remove_device+0x27c/0x560
[ 2257.819338]  arm_smmu_remove_device+0xe8/0x190
[ 2257.819339]  iommu_bus_notifier+0x134/0x248
[ 2257.819342]  notifier_call_chain+0xb0/0x140
[ 2257.819343]  blocking_notifier_call_chain+0x6c/0xd8
[ 2257.819344]  device_del+0x578/0x940
[ 2257.819346]  pci_remove_bus_device+0x114/0x290
[ 2257.819347]  pci_stop_and_remove_bus_device_locked+0x2c/0x40
[ 2257.819349]  remove_store+0xdc/0xe8
[ 2257.819352]  dev_attr_store+0x60/0x80
[ 2257.819353]  sysfs_kf_write+0x104/0x170
[ 2257.819354]  kernfs_fop_write+0x23c/0x430
[ 2257.819355]  __vfs_write+0x7c/0xe8
[ 2257.819357]  vfs_write+0x12c/0x3d0
[ 2257.819358]  ksys_write+0xd4/0x1d8
[ 2257.819359]  __arm64_sys_write+0x70/0xa0
[ 2257.819361]  el0_svc_common+0xfc/0x278
[ 2257.819362]  el0_svc_handler+0x50/0xc0
[ 2257.819364]  el0_svc+0x8/0x1b0
[ 2257.819364]

           T0                                 T1
---------------------------------    ---------------------------------
|- arm_smmu_evtq_thread              |- arm_smmu_remove_device
  |- arm_smmu_handle_evt               |- iommu_group_remove_device
                                         |- kfree(dev->iommu_param)
    |- arm_smmu_find_master
    |- iommu_report_device_fault       |- arm_smmu_remove_master
      |- mutex_lock( \
         &dev->iommu_param->lock)
         // UAF

Reference upstream mainline commit 395ad89d,
move arm_smmu_remove_master() before iommu_group_remove_device(),
and hold mutex to protect finding master and subsequent handling.

Fixes: b525f0a6 ("iommu/arm-smmu-v3: Add stall support for platform devices")
Signed-off-by: NDing Hui <dinghui@sangfor.com.cn>

f7f16389

17 4月, 2023 2 次提交

nfc: st-nci: Fix use after free bug in ndlc_remove due to race condition · a5f1c660

由 Zheng Wang 提交于 4月 17, 2023

mainline inclusion
from mainline-v6.3-rc3
commit 5000fe6c
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6UW64
CVE: CVE-2023-1990

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

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

This bug influences both st_nci_i2c_remove and st_nci_spi_remove.
Take st_nci_i2c_remove as an example.

In st_nci_i2c_probe, it called ndlc_probe and bound &ndlc->sm_work
with llt_ndlc_sm_work.

When it calls ndlc_recv or timeout handler, it will finally call
schedule_work to start the work.

When we call st_nci_i2c_remove to remove the driver, there
may be a sequence as follows:

Fix it by finishing the work before cleanup in ndlc_remove

CPU0                  CPU1

                    |llt_ndlc_sm_work
st_nci_i2c_remove   |
  ndlc_remove       |
     st_nci_remove  |
     nci_free_device|
     kfree(ndev)    |
//free ndlc->ndev   |
                    |llt_ndlc_rcv_queue
                    |nci_recv_frame
                    |//use ndlc->ndev

Fixes: 35630df6 ("NFC: st21nfcb: Add driver for STMicroelectronics ST21NFCB NFC chip")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Reviewed-by: NKrzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230312160837.2040857-1-zyytlz.wz@163.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

a5f1c660

Bluetooth: btsdio: fix use after free bug in btsdio_remove due to race condition · ba592ac9

由 Zheng Wang 提交于 4月 17, 2023

mainline inclusion
from mainline-v6.3-rc7
commit 73f7b171
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6UW68
CVE: CVE-2023-1989

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

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

In btsdio_probe, the data->work is bound with btsdio_work. It will be
started in btsdio_send_frame.

If the btsdio_remove runs with a unfinished work, there may be a race
condition that hdev is freed but used in btsdio_work. Fix it by
canceling the work before do cleanup in btsdio_remove.
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

ba592ac9

11 4月, 2023 1 次提交

hwmon: (xgene) Fix use after free bug in xgene_hwmon_remove due to race condition · 980077ee

由 Zheng Wang 提交于 4月 11, 2023

mainline inclusion
from mainline-v6.3-rc3
commit cb090e64
category: bugfix
bugzilla: 188657, https://gitee.com/src-openeuler/kernel/issues/I6T36A
CVE: CVE-2023-1855

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

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

In xgene_hwmon_probe, &ctx->workq is bound with xgene_hwmon_evt_work.
Then it will be started.

If we remove the driver which will call xgene_hwmon_remove to clean up,
there may be unfinished work.

The possible sequence is as follows:

Fix it by finishing the work before cleanup in xgene_hwmon_remove.

CPU0                  CPU1

                    |xgene_hwmon_evt_work
xgene_hwmon_remove   |
kfifo_free(&ctx->async_msg_fifo);|
                    |
                    |kfifo_out_spinlocked
                    |//use &ctx->async_msg_fifo
Fixes: 2ca492e2 ("hwmon: (xgene) Fix crash when alarm occurs before driver probe")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Link: https://lore.kernel.org/r/20230310084007.1403388-1-zyytlz.wz@163.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NZhao Wenhui <zhaowenhui8@huawei.com>
Reviewed-by: Nsongping yu <yusongping@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

980077ee

10 4月, 2023 2 次提交

xirc2ps_cs: Fix use after free bug in xirc2ps_detach · f4ba1c5f

由 Zheng Wang 提交于 4月 10, 2023

stable inclusion
from stable-v4.19.279
commit 526660c25d3b93b1232a525b75469048388f0928
category: bugfix
bugzilla: 188641, https://gitee.com/src-openeuler/kernel/issues/I6R4MM
CVE: CVE-2023-1670

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

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

[ Upstream commit e8d20c3d ]

In xirc2ps_probe, the local->tx_timeout_task was bounded
with xirc2ps_tx_timeout_task. When timeout occurs,
it will call xirc_tx_timeout->schedule_work to start the
work.

When we call xirc2ps_detach to remove the driver, there
may be a sequence as follows:

Stop responding to timeout tasks and complete scheduled
tasks before cleanup in xirc2ps_detach, which will fix
the problem.

CPU0                  CPU1

                    |xirc2ps_tx_timeout_task
xirc2ps_detach      |
  free_netdev       |
    kfree(dev);     |
                    |
                    | do_reset
                    |   //use dev

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Signed-off-by: NZheng Wang <zyytlz.wz@163.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: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

f4ba1c5f

9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race condition · 6740b62b

由 Zheng Wang 提交于 4月 10, 2023

maillist inclusion
category: bugfix
bugzilla: 188655, https://gitee.com/src-openeuler/kernel/issues/I6T36H
CVE: CVE-2023-1859

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ea4f1009408efb4989a0f139b70fb338e7f687d0

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

In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring
to init priv->rings and bound &ring->work with p9_xen_response.

When it calls xen_9pfs_front_event_handler to handle IRQ requests,
it will finally call schedule_work to start the work.

When we call xen_9pfs_front_remove to remove the driver, there
may be a sequence as follows:

Fix it by finishing the work before cleanup in xen_9pfs_front_free.

Note that, this bug is found by static analysis, which might be
false positive.

CPU0                  CPU1

                     |p9_xen_response
xen_9pfs_front_remove|
  xen_9pfs_front_free|
kfree(priv)          |
//free priv          |
                     |p9_tag_lookup
                     |//use priv->client

Fixes: 71ebd719 ("xen/9pfs: connect to the backend")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Reviewed-by: NMichal Swiatkowski <michal.swiatkowski@linux.intel.com>
Signed-off-by: NEric Van Hensbergen <ericvh@kernel.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: NYongqiang Liu <liuyongqiang13@huawei.com>

6740b62b

08 4月, 2023 10 次提交

!566 linux-4.19.y bugfixes backport · ce8f76ce

由 openeuler-ci-bot 提交于 4月 08, 2023

Merge Pull Request from: @LiuYongQiang0816 
 
20 bugfixes from linux-4.19.y 
 
Link:https://gitee.com/openeuler/kernel/pulls/566 

Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com>

ce8f76ce

bpf: add missing header file include · c6efc48a

由 Linus Torvalds 提交于 4月 08, 2023

stable inclusion
from stable-v4.19.274
commit c7603df97635954165fb599e64e197efc353979b
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1
CVE: NA

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

commit f3dd0c53 upstream.

Commit 74e19ef0 ("uaccess: Add speculation barrier to
copy_from_user()") built fine on x86-64 and arm64, and that's the extent
of my local build testing.

It turns out those got the <linux/nospec.h> include incidentally through
other header files (<linux/kvm_host.h> in particular), but that was not
true of other architectures, resulting in build errors

  kernel/bpf/core.c: In function ‘___bpf_prog_run’:
  kernel/bpf/core.c:1913:3: error: implicit declaration of function ‘barrier_nospec’

so just make sure to explicitly include the proper <linux/nospec.h>
header file to make everybody see it.

Fixes: 74e19ef0 ("uaccess: Add speculation barrier to copy_from_user()")
Reported-by: Nkernel test robot <lkp@intel.com>
Reported-by: NViresh Kumar <viresh.kumar@linaro.org>
Reported-by: NHuacai Chen <chenhuacai@loongson.cn>
Tested-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Tested-by: NDave Hansen <dave.hansen@linux.intel.com>
Acked-by: NAlexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

c6efc48a

uaccess: Add speculation barrier to copy_from_user() · bb47af81

由 Dave Hansen 提交于 4月 07, 2023

stable inclusion
from stable-v4.19.274
commit f8e54da1c729cc23d9a7b7bd42379323e7fb7979
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1
CVE: NA

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

commit 74e19ef0 upstream.

The results of "access_ok()" can be mis-speculated.  The result is that
you can end speculatively:

	if (access_ok(from, size))
		// Right here

even for bad from/size combinations.  On first glance, it would be ideal
to just add a speculation barrier to "access_ok()" so that its results
can never be mis-speculated.

But there are lots of system calls just doing access_ok() via
"copy_to_user()" and friends (example: fstat() and friends).  Those are
generally not problematic because they do not _consume_ data from
userspace other than the pointer.  They are also very quick and common
system calls that should not be needlessly slowed down.

"copy_from_user()" on the other hand uses a user-controller pointer and
is frequently followed up with code that might affect caches.  Take
something like this:

	if (!copy_from_user(&kernelvar, uptr, size))
		do_something_with(kernelvar);

If userspace passes in an evil 'uptr' that *actually* points to a kernel
addresses, and then do_something_with() has cache (or other)
side-effects, it could allow userspace to infer kernel data values.

Add a barrier to the common copy_from_user() code to prevent
mis-speculated values which happen after the copy.

Also add a stub for architectures that do not define barrier_nospec().
This makes the macro usable in generic code.

Since the barrier is now usable in generic code, the x86 #ifdef in the
BPF code can also go away.
Reported-by: NJordy Zomer <jordyzomer@google.com>
Suggested-by: NLinus Torvalds <torvalds@linuxfoundation.org>
Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>   # BPF bits
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Conflicts:
	lib/usercopy.c
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>
Reviewed-by: NNanyong Sun <sunnanyong@huawei.com>
Reviewed-by: Ntong tiangen <tongtiangen@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

bb47af81

random: always mix cycle counter in add_latent_entropy() · fff09007

由 Jason A. Donenfeld 提交于 4月 07, 2023

stable inclusion
from stable-v4.19.274
commit e4935368448ce8097dada35163598e93567f1110
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1
CVE: NA

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

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

[ Upstream commit d7bf7f3b ]

add_latent_entropy() is called every time a process forks, in
kernel_clone(). This in turn calls add_device_randomness() using the
latent entropy global state. add_device_randomness() does two things:

   2) Mixes into the input pool the latent entropy argument passed; and
   1) Mixes in a cycle counter, a sort of measurement of when the event
      took place, the high precision bits of which are presumably
      difficult to predict.

(2) is impossible without CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y. But (1) is
always possible. However, currently CONFIG_GCC_PLUGIN_LATENT_ENTROPY=n
disables both (1) and (2), instead of just (2).

This commit causes the CONFIG_GCC_PLUGIN_LATENT_ENTROPY=n case to still
do (1) by passing NULL (len 0) to add_device_randomness() when add_latent_
entropy() is called.

Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: PaX Team <pageexec@freemail.hu>
Cc: Emese Revfy <re.emese@gmail.com>
Fixes: 38addce8 ("gcc-plugins: Add latent_entropy plugin")
Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>

Conflicts:
	include/linux/random.h
Signed-off-by: NCui GaoSheng <cuigaosheng1@huawei.com>
Reviewed-by: Nyiyang <yiyang13@huawei.com>
Reviewed-by: Nguozihua <guozihua@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

fff09007

x86/mm: Fix use of uninitialized buffer in sme_enable() · 8295451e

由 Nikita Zhandarovich 提交于 4月 07, 2023

stable inclusion
from stable-v4.19.279
commit ffdf8d81c48822a329af9f31dc239090f4a60761
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1
CVE: NA

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

commit cbebd68f upstream.

cmdline_find_option() may fail before doing any initialization of
the buffer array. This may lead to unpredictable results when the same
buffer is used later in calls to strncmp() function.  Fix the issue by
returning early if cmdline_find_option() returns an error.

Found by Linux Verification Center (linuxtesting.org) with static
analysis tool SVACE.

Fixes: aca20d54 ("x86/mm: Add support to make use of Secure Memory Encryption")
Signed-off-by: NNikita Zhandarovich <n.zhandarovich@fintech.ru>
Signed-off-by: NBorislav Petkov (AMD) <bp@alien8.de>
Acked-by: NTom Lendacky <thomas.lendacky@amd.com>
Cc: <stable@kernel.org>
Link: https://lore.kernel.org/r/20230306160656.14844-1-n.zhandarovich@fintech.ruSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

8295451e

ext4: fail ext4_iget if special inode unallocated · 9188d638

由 Baokun Li 提交于 4月 07, 2023

stable inclusion
from stable-v4.19.279
commit 3aea195acd977e82d970cbc7078f983880c7ee6a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1
CVE: NA

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

[ Upstream commit 5cd74028 ]

In ext4_fill_super(), EXT4_ORPHAN_FS flag is cleared after
ext4_orphan_cleanup() is executed. Therefore, when __ext4_iget() is
called to get an inode whose i_nlink is 0 when the flag exists, no error
is returned. If the inode is a special inode, a null pointer dereference
may occur. If the value of i_nlink is 0 for any inodes (except boot loader
inodes) got by using the EXT4_IGET_SPECIAL flag, the current file system
is corrupted. Therefore, make the ext4_iget() function return an error if
it gets such an abnormal special inode.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=199179
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216541
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216539Reported-by: NLuís Henriques <lhenriques@suse.de>
Suggested-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NBaokun Li <libaokun1@huawei.com>
Reviewed-by: NJan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20230107032126.4165860-2-libaokun1@huawei.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

9188d638

ext4: zero i_disksize when initializing the bootloader inode · 484d2779

由 Zhihao Cheng 提交于 4月 07, 2023

stable inclusion
from stable-v4.19.278
commit 59eee0cdf8c036f554add97a4da7c06d7a9ff34a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1
CVE: NA

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

commit f5361da1 upstream.

If the boot loader inode has never been used before, the
EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the
i_size to 0.  However, if the "never before used" boot loader has a
non-zero i_size, then i_disksize will be non-zero, and the
inconsistency between i_size and i_disksize can trigger a kernel
warning:

 WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319
 CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa
 RIP: 0010:ext4_file_write_iter+0xbc7/0xd10
 Call Trace:
  vfs_write+0x3b1/0x5c0
  ksys_write+0x77/0x160
  __x64_sys_write+0x22/0x30
  do_syscall_64+0x39/0x80

Reproducer:
 1. create corrupted image and mount it:
       mke2fs -t ext4 /tmp/foo.img 200
       debugfs -wR "sif <5> size 25700" /tmp/foo.img
       mount -t ext4 /tmp/foo.img /mnt
       cd /mnt
       echo 123 > file
 2. Run the reproducer program:
       posix_memalign(&buf, 1024, 1024)
       fd = open("file", O_RDWR | O_DIRECT);
       ioctl(fd, EXT4_IOC_SWAP_BOOT);
       write(fd, buf, 1024);

Fix this by setting i_disksize as well as i_size to zero when
initiaizing the boot loader inode.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=217159
Cc: stable@kernel.org
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
Link: https://lore.kernel.org/r/20230308032643.641113-1-chengzhihao1@huawei.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

484d2779

irqdomain: Drop bogus fwspec-mapping error handling · 8c2b6143

由 Johan Hovold 提交于 4月 07, 2023

stable inclusion
from stable-v4.19.276
commit 525eb5cb8edfb7014711c2c87827ed17af8872fb
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1
CVE: NA

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

commit e3b7ab02 upstream.

In case a newly allocated IRQ ever ends up not having any associated
struct irq_data it would not even be possible to dispose the mapping.

Replace the bogus disposal with a WARN_ON().

This will also be used to fix a shared-interrupt mapping race, hence the
CC-stable tag.

Fixes: 1e2a7d78 ("irqdomain: Don't set type when mapping an IRQ")
Cc: stable@vger.kernel.org      # 4.8
Tested-by: NHsin-Yi Wang <hsinyi@chromium.org>
Tested-by: NMark-PK Tsai <mark-pk.tsai@mediatek.com>
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230213104302.17307-4-johan+linaro@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

8c2b6143

irqdomain: Fix disassociation race · 02f71880

由 Johan Hovold 提交于 4月 07, 2023

stable inclusion
from stable-v4.19.276
commit 1b9fe6e4930155f1083a4dc32d3a47b1c4e8f55c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1
CVE: NA

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

commit 3f883c38 upstream.

The global irq_domain_mutex is held when mapping interrupts from
non-hierarchical domains but currently not when disposing them.

This specifically means that updates of the domain mapcount is racy
(currently only used for statistics in debugfs).

Make sure to hold the global irq_domain_mutex also when disposing
mappings from non-hierarchical domains.

Fixes: 9dc6be3d ("genirq/irqdomain: Add map counter")
Cc: stable@vger.kernel.org      # 4.13
Tested-by: NHsin-Yi Wang <hsinyi@chromium.org>
Tested-by: NMark-PK Tsai <mark-pk.tsai@mediatek.com>
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230213104302.17307-3-johan+linaro@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

02f71880

irqdomain: Fix association race · 1db52082

由 Johan Hovold 提交于 4月 07, 2023

stable inclusion
from stable-v4.19.276
commit 2dcccf91bc4e9937dccf86c9b1f5026ffd72a80b
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TIG1
CVE: NA

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

commit b06730a5 upstream.

The sanity check for an already mapped virq is done outside of the
irq_domain_mutex-protected section which means that an (unlikely) racing
association may not be detected.

Fix this by factoring out the association implementation, which will
also be used in a follow-on change to fix a shared-interrupt mapping
race.

Fixes: ddaf144c ("irqdomain: Refactor irq_domain_associate_many()")
Cc: stable@vger.kernel.org      # 3.11
Tested-by: NHsin-Yi Wang <hsinyi@chromium.org>
Tested-by: NMark-PK Tsai <mark-pk.tsai@mediatek.com>
Signed-off-by: NJohan Hovold <johan+linaro@kernel.org>
Signed-off-by: NMarc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230213104302.17307-2-johan+linaro@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

1db52082

openeuler / Kernel 接近 2 年 前同步成功

openeuler / Kernel
接近 2 年前同步成功