mainline inclusion
from mainline-v6.2-rc6
commit 6f1d64b1
category: bugfix
bugzilla: 188443, https://gitee.com/openeuler/kernel/issues/I6I8YD
CVE: NA

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

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

Bug report and analysis from Ding Hui.

During iSCSI session logout, if another task accesses the shost ipaddress
attr, we can get a KASAN UAF report like this:

[  276.942144] BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x78/0xe0
[  276.942535] Write of size 4 at addr ffff8881053b45b8 by task cat/4088
[  276.943511] CPU: 2 PID: 4088 Comm: cat Tainted: G            E      6.1.0-rc8+ #3
[  276.943997] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[  276.944470] Call Trace:
[  276.944943]  <TASK>
[  276.945397]  dump_stack_lvl+0x34/0x48
[  276.945887]  print_address_description.constprop.0+0x86/0x1e7
[  276.946421]  print_report+0x36/0x4f
[  276.947358]  kasan_report+0xad/0x130
[  276.948234]  kasan_check_range+0x35/0x1c0
[  276.948674]  _raw_spin_lock_bh+0x78/0xe0
[  276.949989]  iscsi_sw_tcp_host_get_param+0xad/0x2e0 [iscsi_tcp]
[  276.951765]  show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0xe9/0x130 [scsi_transport_iscsi]
[  276.952185]  dev_attr_show+0x3f/0x80
[  276.953005]  sysfs_kf_seq_show+0x1fb/0x3e0
[  276.953401]  seq_read_iter+0x402/0x1020
[  276.954260]  vfs_read+0x532/0x7b0
[  276.955113]  ksys_read+0xed/0x1c0
[  276.955952]  do_syscall_64+0x38/0x90
[  276.956347]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  276.956769] RIP: 0033:0x7f5d3a679222
[  276.957161] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 32 c0 0b 00 e8 a5 fe 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24
[  276.958009] RSP: 002b:00007ffc864d16a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[  276.958431] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5d3a679222
[  276.958857] RDX: 0000000000020000 RSI: 00007f5d3a4fe000 RDI: 0000000000000003
[  276.959281] RBP: 00007f5d3a4fe000 R08: 00000000ffffffff R09: 0000000000000000
[  276.959682] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020000
[  276.960126] R13: 0000000000000003 R14: 0000000000000000 R15: 0000557a26dada58
[  276.960536]  </TASK>
[  276.961357] Allocated by task 2209:
[  276.961756]  kasan_save_stack+0x1e/0x40
[  276.962170]  kasan_set_track+0x21/0x30
[  276.962557]  __kasan_kmalloc+0x7e/0x90
[  276.962923]  __kmalloc+0x5b/0x140
[  276.963308]  iscsi_alloc_session+0x28/0x840 [scsi_transport_iscsi]
[  276.963712]  iscsi_session_setup+0xda/0xba0 [libiscsi]
[  276.964078]  iscsi_sw_tcp_session_create+0x1fd/0x330 [iscsi_tcp]
[  276.964431]  iscsi_if_create_session.isra.0+0x50/0x260 [scsi_transport_iscsi]
[  276.964793]  iscsi_if_recv_msg+0xc5a/0x2660 [scsi_transport_iscsi]
[  276.965153]  iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]
[  276.965546]  netlink_unicast+0x4d5/0x7b0
[  276.965905]  netlink_sendmsg+0x78d/0xc30
[  276.966236]  sock_sendmsg+0xe5/0x120
[  276.966576]  ____sys_sendmsg+0x5fe/0x860
[  276.966923]  ___sys_sendmsg+0xe0/0x170
[  276.967300]  __sys_sendmsg+0xc8/0x170
[  276.967666]  do_syscall_64+0x38/0x90
[  276.968028]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[  276.968773] Freed by task 2209:
[  276.969111]  kasan_save_stack+0x1e/0x40
[  276.969449]  kasan_set_track+0x21/0x30
[  276.969789]  kasan_save_free_info+0x2a/0x50
[  276.970146]  __kasan_slab_free+0x106/0x190
[  276.970470]  __kmem_cache_free+0x133/0x270
[  276.970816]  device_release+0x98/0x210
[  276.971145]  kobject_cleanup+0x101/0x360
[  276.971462]  iscsi_session_teardown+0x3fb/0x530 [libiscsi]
[  276.971775]  iscsi_sw_tcp_session_destroy+0xd8/0x130 [iscsi_tcp]
[  276.972143]  iscsi_if_recv_msg+0x1bf1/0x2660 [scsi_transport_iscsi]
[  276.972485]  iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]
[  276.972808]  netlink_unicast+0x4d5/0x7b0
[  276.973201]  netlink_sendmsg+0x78d/0xc30
[  276.973544]  sock_sendmsg+0xe5/0x120
[  276.973864]  ____sys_sendmsg+0x5fe/0x860
[  276.974248]  ___sys_sendmsg+0xe0/0x170
[  276.974583]  __sys_sendmsg+0xc8/0x170
[  276.974891]  do_syscall_64+0x38/0x90
[  276.975216]  entry_SYSCALL_64_after_hwframe+0x63/0xcd

We can easily reproduce by two tasks:
1. while :; do iscsiadm -m node --login; iscsiadm -m node --logout; done
2. while :; do cat \
/sys/devices/platform/host*/iscsi_host/host*/ipaddress; done

            iscsid              |        cat
--------------------------------+---------------------------------------
|- iscsi_sw_tcp_session_destroy |
  |- iscsi_session_teardown     |
    |- device_release           |
      |- iscsi_session_release  ||- dev_attr_show
        |- kfree                |  |- show_host_param_
                                |             ISCSI_HOST_PARAM_IPADDRESS
                                |    |- iscsi_sw_tcp_host_get_param
                                |      |- r/w tcp_sw_host->session (UAF)
  |- iscsi_host_remove          |
  |- iscsi_host_free            |

Fix the above bug by splitting the session removal into 2 parts:

 1. removal from iSCSI class which includes sysfs and removal from host
    tracking.

 2. freeing of session.

During iscsi_tcp host and session removal we can remove the session from
sysfs then remove the host from sysfs. At this point we know userspace is
not accessing the kernel via sysfs so we can free the session and host.

Link: https://lore.kernel.org/r/20230117193937.21244-2-michael.christie@oracle.comSigned-off-by: NMike Christie <michael.christie@oracle.com>
Reviewed-by: NLee Duncan <lduncan@suse.com>
Acked-by: NDing Hui <dinghui@sangfor.com.cn>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
conflicts:
	drivers/scsi/iscsi_tcp.c
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v5.14-rc1
commit a1f3486b
category: bugfix
bugzilla: 188443, https://gitee.com/openeuler/kernel/issues/I6I8YD
CVE: NA

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

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

This doesn't fix any bugs, but it makes more sense to free the pool after
we have removed the session. At that time we know nothing is touching any
of the session fields, because all devices have been removed and scans are
stopped.

Link: https://lore.kernel.org/r/20210525181821.7617-19-michael.christie@oracle.comReviewed-by: NLee Duncan <lduncan@suse.com>
Signed-off-by: NMike Christie <michael.christie@oracle.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I66W4Y
CVE: NA

workaround if multiple functions on a PCl device belong to the same
IOMMU group, they can be directly assigned to only one VM as well,
letting multiple functions belong to different IOMMU group.
Signed-off-by: NDuanqiang Wen <duanqiangwen@net-swift.com>
(cherry picked from commit ed2b7e53)

hulk inclusion
category: bugfix
bugzilla: 188150, https://gitee.com/openeuler/kernel/issues/I643OL

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

This reverts commit e06779a6.

This commit has a soft lock problem:

watchdog: BUG: soft lockup - CPU#22 stuck for 67s! [iscsid:16369]
 Call Trace:
  scsi_remove_target+0x548/0x7b0
  ? sdev_store_delete+0x90/0x90
  ? __mutex_lock_slowpath+0x10/0x10
  ? device_remove_class_symlinks+0x1b0/0x1b0
  __iscsi_unbind_session+0x16b/0x250 [scsi_transport_iscsi]
  iscsi_remove_session+0x1d3/0x2f0 [scsi_transport_iscsi]
  iscsi_session_remove+0x5c/0x80 [libiscsi]
  iscsi_sw_tcp_session_destroy+0xd3/0x160 [iscsi_tcp]
  iscsi_if_rx+0x2369/0x5060 [scsi_transport_iscsi]

The reason is that if other threads hold the reference count of the
kobject while waiting for the device to be released, it will keep
waiting in a loop.

Fixes: e06779a6 ("scsi: fix iscsi rescan fails to create block")
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.169
commit 045a31b9
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6IXQP
CVE: CVE-2023-23000

Reference: https://github.com/torvalds/linux/commit/045a31b95509c8f25f5f04ec5e0dec5cd09f2c5f

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

commit 045a31b9 upstream.

callers of tegra_xusb_find_port_node() function only do NULL checking for
the return value. return NULL instead of ERR_PTR(-ENOMEM) to keep
consistent.
Signed-off-by: NMiaoqian Lin <linmq006@gmail.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/20211213020507.1458-1-linmq006@gmail.comSigned-off-by: NVinod Koul <vkoul@kernel.org>
Signed-off-by: Nsanglipeng <sanglipeng1@jd.com>

mainline inclusion
from mainline-v6.3-rc1
commit 29b0589a
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6IW01
CVE: CVE-2023-1118

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

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

When the ene device is detaching, function ene_remove() will
be called. But there is no function to cancel tx_sim_timer
in ene_remove(), the timer handler ene_tx_irqsim() could race
with ene_remove(). As a result, the UAF bugs could happen,
the process is shown below.

    (cleanup routine)          |        (timer routine)
                               | mod_timer(&dev->tx_sim_timer, ..)
ene_remove()                   | (wait a time)
                               | ene_tx_irqsim()
                               |   dev->hw_lock //USE
                               |   ene_tx_sample(dev) //USE

Fix by adding del_timer_sync(&dev->tx_sim_timer) in ene_remove(),
The tx_sim_timer could stop before ene device is deallocated.

What's more, The rc_unregister_device() and del_timer_sync()
should be called first in ene_remove() and the deallocated
functions such as free_irq(), release_region() and so on
should be called behind them. Because the rc_unregister_device()
is well synchronized. Otherwise, race conditions may happen. The
situations that may lead to race conditions are shown below.

Firstly, the rx receiver is disabled with ene_rx_disable()
before rc_unregister_device() in ene_remove(), which means it
can be enabled again if a process opens /dev/lirc0 between
ene_rx_disable() and rc_unregister_device().

Secondly, the irqaction descriptor is freed by free_irq()
before the rc device is unregistered, which means irqaction
descriptor may be accessed again after it is deallocated.

Thirdly, the timer can call ene_tx_sample() that can write
to the io ports, which means the io ports could be accessed
again after they are deallocated by release_region().

Therefore, the rc_unregister_device() and del_timer_sync()
should be called first in ene_remove().

Suggested by: Sean Young <sean@mess.org>

Fixes: 9ea53b74 ("V4L/DVB: STAGING: remove lirc_ene0100 driver")
Signed-off-by: NDuoming Zhou <duoming@zju.edu.cn>
Signed-off-by: NSean Young <sean@mess.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NRen Zhijie <renzhijie2@huawei.com>
Reviewed-by: Nsongping yu <yusongping@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Reviewed-by: Nchenhui <judy.chenhui@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.166
commit 20fd4598762e2d717deb64ef028e6f5f587ac2a6
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6KCIO
CVE: CVE-2023-1073

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

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

Add a check for empty report_list in bigben_probe().
The missing check causes a type confusion when issuing a list_entry()
on an empty report_list.
The problem is caused by the assumption that the device must
have valid report_list. While this will be true for all normal HID
devices, a suitably malicious device can violate the assumption.

Fixes: 256a90ed ("HID: hid-bigbenff: driver for BigBen Interactive PS3OFMINIPAD gamepad")
Signed-off-by: NPietro Borrello <borrello@diag.uniroma1.it>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NLin Yujun <linyujun809@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.166
commit 5dc3469a1170dd1344d262a332b26994214eeb58
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6KCIO
CVE: CVE-2023-1073

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

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

Add a check for empty report_list in hid_validate_values().
The missing check causes a type confusion when issuing a list_entry()
on an empty report_list.
The problem is caused by the assumption that the device must
have valid report_list. While this will be true for all normal HID
devices, a suitably malicious device can violate the assumption.

Fixes: 1b15d2e5 ("HID: core: fix validation of report id 0")
Signed-off-by: NPietro Borrello <borrello@diag.uniroma1.it>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
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>

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

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

raid10_sync_request() will add 'r10bio->remaining' for both rdev and
replacement rdev. However, if the read io failed,
recovery_request_write() will return without issuring the write io, in
this case, end_sync_request() is only called once and 'remaining' is
leaked, which will cause io hang.

Fix the probleming by decreasing 'remaining' according to if 'bio' and
'repl_bio' is valid.

Fixes: 24afd80d ("md/raid10: handle recovery of replacement devices.")
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

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

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

status_resync() will calculate 'curr_resync - recovery_active' to show
user a progress bar like following:

[============>........]  resync = 61.4%

'curr_resync' and 'recovery_active' is updated in md_do_sync(), and
status_resync() can read them concurrently, hence it's possible that
'curr_resync - recovery_active' can overflow to a huge number. In this
case status_resync() will be stuck in the loop to print a large amount
of '=', which will end up soft lockup.

Fix the problem by setting 'resync' to MD_RESYNC_ACTIVE in this case,
this way resync in progress will be reported to user.
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.3-rc1
commit 1d1f25bf
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6JN1I
CVE: NA

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

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

Don't update recovery_cp when curr_resync is MD_RESYNC_ACTIVE, otherwise
md may skip the resync of the first 3 sectors if the resync procedure is
interrupted before the first calling of ->sync_request() as shown below:

md_do_sync thread          control thread
  // setup resync
  mddev->recovery_cp = 0
  j = 0
  mddev->curr_resync = MD_RESYNC_ACTIVE

                             // e.g., set array as idle
                             set_bit(MD_RECOVERY_INTR, &&mddev_recovery)
  // resync loop
  // check INTR before calling sync_request
  !test_bit(MD_RECOVERY_INTR, &mddev->recovery

  // resync interrupted
  // update recovery_cp from 0 to 3
  // the resync of three 3 sectors will be skipped
  mddev->recovery_cp = 3

Fixes: eac58d08 ("md: Use enum for overloaded magic numbers used by mddev->curr_resync")
Cc: stable@vger.kernel.org # 6.0+
Signed-off-by: NHou Tao <houtao1@huawei.com>
Reviewed-by: NLogan Gunthorpe <logang@deltatee.com>
Signed-off-by: NSong Liu <song@kernel.org>
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.0-rc1
commit b368856a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6JN1I
CVE: NA

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

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

The 07layouts test in mdadm fails on some systems. The failure
presents itself as the backup file not being removed before the next
layout is grown into:

  mdadm: /dev/md0: cannot create backup file /tmp/md-test-backup:
      File exists

This is because the background mdadm process, which is responsible for
cleaning up this backup file gets into an infinite loop waiting for
the reshape to start. mdadm checks the mdstat file if a reshape is
going and, if it is not, it waits for an event on the file or times
out in 5 seconds. On faster machines, the reshape may complete before
the 5 seconds times out, and thus the background mdadm process loops
waiting for a reshape to start that has already occurred.

mdadm reads the mdstat file to start, but mdstat does not report that the
reshape has begun, even though it has indeed begun. So the mdstat_wait()
call (in mdadm) which polls on the mdstat file won't ever return until
timing out.

The reason mdstat reports the reshape has started is due to an issue
in status_resync(). recovery_active is subtracted from curr_resync which
will result in a value of zero for the first chunk of reshaped data, and
the resulting read will report no reshape in progress.

To fix this, if "resync - recovery_active" is an overloaded value, force
the value to be MD_RESYNC_ACTIVE so the code reports a resync in progress.
Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NSong Liu <song@kernel.org>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.0-rc1
commit eac58d08
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6JN1I
CVE: NA

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

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

Comments in the code document special values used for
mddev->curr_resync. Make this clearer by using an enum to label these
values.

The only functional change is a couple places use the wrong comparison
operator that implied 3 is another special value. They are all
fixed to imply that 3 or greater is an active resync.
Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NSong Liu <song@kernel.org>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

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

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

handle_read_error() will resumit r10_bio by raid10_read_request(), which
will call bio_start_io_acct() again, while bio_end_io_acct() will only
be called once.

Fix the problem by don't account io again from handle_read_error().

Fixes: 528bc2cf ("md/raid10: enable io accounting")
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v5.17-rc1
commit fa0ef938
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6IEH4
CVE: CVE-2023-22995

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

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

Add the missing platform_device_put() before return from
dwc3_qcom_acpi_register_core in the error handling case.
Signed-off-by: NMiaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20211231113641.31474-1-linmq006@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes: 2bc02355 ("usb: dwc3: qcom: Add support for booting with ACPI")
[Fix conflict due to lack of 8dc6e6dd]
Conflict:
	drivers/usb/dwc3/dwc3-qcom.c
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.3-rc1
commit 66b2c338
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6I7UC
CVE: CVE-2023-1076

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

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

sock_init_data() assumes that the `struct socket` passed in input is
contained in a `struct socket_alloc` allocated with sock_alloc().
However, tap_open() passes a `struct socket` embedded in a `struct
tap_queue` allocated with sk_alloc().
This causes a type confusion when issuing a container_of() with
SOCK_INODE() in sock_init_data() which results in assigning a wrong
sk_uid to the `struct sock` in input.
On default configuration, the type confused field overlaps with
padding bytes between `int vnet_hdr_sz` and `struct tap_dev __rcu
*tap` in `struct tap_queue`, which makes the uid of all tap sockets 0,
i.e., the root one.
Fix the assignment by using sock_init_data_uid().

Fixes: 86741ec2 ("net: core: Add a UID field to struct sock.")
Signed-off-by: NPietro Borrello <borrello@diag.uniroma1.it>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-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>

mainline inclusion
from mainline-v6.3-rc1
commit a096ccca
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6I7UC
CVE: CVE-2023-1076

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

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

sock_init_data() assumes that the `struct socket` passed in input is
contained in a `struct socket_alloc` allocated with sock_alloc().
However, tun_chr_open() passes a `struct socket` embedded in a `struct
tun_file` allocated with sk_alloc().
This causes a type confusion when issuing a container_of() with
SOCK_INODE() in sock_init_data() which results in assigning a wrong
sk_uid to the `struct sock` in input.
On default configuration, the type confused field overlaps with the
high 4 bytes of `struct tun_struct __rcu *tun` of `struct tun_file`,
NULL at the time of call, which makes the uid of all tun sockets 0,
i.e., the root one.
Fix the assignment by using sock_init_data_uid().

Fixes: 86741ec2 ("net: core: Add a UID field to struct sock.")
Signed-off-by: NPietro Borrello <borrello@diag.uniroma1.it>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-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>

stable inclusion
from stable-v5.10.157
commit ae9e0cc973fb7499ea1b1a8dfd0795f728b84faf
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6DKVG
CVE: CVE-2023-20938

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

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

commit ef38de92 upstream.

Some android userspace is sending BINDER_TYPE_FDA objects with
num_fds=0. Like the previous patch, this is reproducible when
playing a video.

Before commit 09184ae9 BINDER_TYPE_FDA objects with num_fds=0
were 'correctly handled', as in no fixup was performed.

After commit 09184ae9 we aggregate fixup and skip regions in
binder_ptr_fixup structs and distinguish between the two by using
the skip_size field: if it's 0, then it's a fixup, otherwise skip.
When processing BINDER_TYPE_FDA objects with num_fds=0 we add a
skip region of skip_size=0, and this causes issues because now
binder_do_deferred_txn_copies will think this was a fixup region.

To address that, return early from binder_translate_fd_array to
avoid adding an empty skip region.

Fixes: 09184ae9 ("binder: defer copies of pre-patched txn data")
Acked-by: NTodd Kjos <tkjos@google.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NAlessandro Astone <ales.astone@gmail.com>
Link: https://lore.kernel.org/r/20220415120015.52684-1-ales.astone@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NCarlos Llamas <cmllamas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.157
commit 017de842533f4334d646f1d480f591f4ca9f5c7a
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6DKVG
CVE: CVE-2023-20938

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

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

commit 2d1746e3 upstream.

When handling BINDER_TYPE_FDA object we are pushing a parent fixup
with a certain skip_size but no scatter-gather copy object, since
the copy is handled standalone.
If BINDER_TYPE_FDA is the last children the scatter-gather copy
loop will never stop to skip it, thus we are left with an item in
the parent fixup list. This will trigger the BUG_ON().

This is reproducible in android when playing a video.
We receive a transaction that looks like this:
    obj[0] BINDER_TYPE_PTR, parent
    obj[1] BINDER_TYPE_PTR, child
    obj[2] BINDER_TYPE_PTR, child
    obj[3] BINDER_TYPE_FDA, child

Fixes: 09184ae9 ("binder: defer copies of pre-patched txn data")
Acked-by: NTodd Kjos <tkjos@google.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NAlessandro Astone <ales.astone@gmail.com>
Link: https://lore.kernel.org/r/20220415120015.52684-2-ales.astone@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NCarlos Llamas <cmllamas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.157
commit 2e3c27f24173c6f3d799080da82126fa044a2f5e
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6DKVG
CVE: CVE-2023-20938

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

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

commit 9a0a930f upstream.

binder_uintptr_t is not the same as uintptr_t, so converting it into a
pointer requires a second cast:

drivers/android/binder.c: In function 'binder_translate_fd_array':
drivers/android/binder.c:2511:28: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
 2511 |         sender_ufda_base = (void __user *)sender_uparent->buffer + fda->parent_offset;
      |                            ^

Fixes: 656e01f3 ("binder: read pre-translated fds from sender buffer")
Acked-by: NTodd Kjos <tkjos@google.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Acked-by: NChristian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20211207122448.1185769-1-arnd@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NCarlos Llamas <cmllamas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.157
commit c9d3f25a7f4e3aab3dfd91885e3d428bccdcb0e1
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6DKVG
CVE: CVE-2023-20938

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

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

commit 09184ae9 upstream.

BINDER_TYPE_PTR objects point to memory areas in the
source process to be copied into the target buffer
as part of a transaction. This implements a scatter-
gather model where non-contiguous memory in a source
process is "gathered" into a contiguous region in
the target buffer.

The data can include pointers that must be fixed up
to correctly point to the copied data. To avoid making
source process pointers visible to the target process,
this patch defers the copy until the fixups are known
and then copies and fixeups are done together.

There is a special case of BINDER_TYPE_FDA which applies
the fixup later in the target process context. In this
case the user data is skipped (so no untranslated fds
become visible to the target).
Reviewed-by: NMartijn Coenen <maco@android.com>
Signed-off-by: NTodd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20211130185152.437403-5-tkjos@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
[cmllamas: fix trivial merge conflict]
Signed-off-by: NCarlos Llamas <cmllamas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.157
commit 5204296fc76623552d53f042e2dc411b49c151f2
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6DKVG
CVE: CVE-2023-20938

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

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

commit 656e01f3 upstream.

This patch is to prepare for an up coming patch where we read
pre-translated fds from the sender buffer and translate them before
copying them to the target.  It does not change run time.

The patch adds two new parameters to binder_translate_fd_array() to
hold the sender buffer and sender buffer parent.  These parameters let
us call copy_from_user() directly from the sender instead of using
binder_alloc_copy_from_buffer() to copy from the target.  Also the patch
adds some new alignment checks.  Previously the alignment checks would
have been done in a different place, but this lets us print more
useful error messages.
Reviewed-by: NMartijn Coenen <maco@android.com>
Acked-by: NChristian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: NTodd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20211130185152.437403-4-tkjos@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NCarlos Llamas <cmllamas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.157
commit 23e9d815fad84c1bee3742a8de4bd39510435362
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6DKVG
CVE: CVE-2023-20938

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

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

commit 6d98eb95 upstream.

Transactions are copied from the sender to the target
first and objects like BINDER_TYPE_PTR and BINDER_TYPE_FDA
are then fixed up. This means there is a short period where
the sender's version of these objects are visible to the
target prior to the fixups.

Instead of copying all of the data first, copy data only
after any needed fixups have been applied.

Fixes: 457b9a6f ("Staging: android: add binder driver")
Reviewed-by: NMartijn Coenen <maco@android.com>
Acked-by: NChristian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: NTodd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20211130185152.437403-3-tkjos@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
[cmllamas: fix trivial merge conflict]
Signed-off-by: NCarlos Llamas <cmllamas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

Offering: HULK
hulk inclusion
category: bugfix
bugzilla: 188413, https://gitee.com/openeuler/kernel/issues/I6GWYG

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

A panic error is like below:

nbd_genl_connect
 nbd_dev_add
   first_minor = index << part_shift; // index =-1
   ...
   __device_add_disk
     blk_alloc_devt
       *devt = MKDEV(disk->major, disk->first_minor + part->partno);
       // part->partno = 0， first_minor = 11...110000 major is covered

There, index < 0 will reassign an index, but here disk->first_minor is
assigned -1 << part_shift.

This causes to the creation of the device with the same major and minor
device numbers each time the incoming index<0, and this will lead to
creation of kobject failed:
Warning: kobject_add_internal failed for 4095:1048544 with -EEXIST, don't
try to register things with the same name in the same directory.

Fix it by moving the first_minor assignment down to after getting the new
index.

Fixes: 60141517 ("nbd: Fix use-after-free in blk_mq_free_rqs")
Signed-off-by: NZhong Jinghua <zhongjinghua@huawei.com>
Reviewed-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

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

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

max_corr_read_errors should not be negative number. Change it to
unsigned int where use it.
Signed-off-by: NLi Nan <linan122@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

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

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

There is no input check when echo md/safe_mode_delay, and overflow will
occur. There is risk of overflow in strict_strtoul_scaled(), too. Fixed
it by using kstrtoul instead of parsing word one by one.
Signed-off-by: NLi Nan <linan122@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

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

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

There is a bug if we write a large number to md/bitmap_set_bits.
md_bitmap_checkpage() returned -EINVAL if "page >= bitmap->pages", but the
return value was not checked immediately in md_bitmap_get_counter() in
order to set *blocks value. fix it by checking page before operate
bitmap.
Signed-off-by: NLi Nan <linan122@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.162
commit 57b20530363d127ab6a82e336275769258eb5f37
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6BTWC
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.168&id=57b20530363d127ab6a82e336275769258eb5f37

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

[ Upstream commit 9fe83c43 ]

The function close_fd_get_file is explicitly a variant of
__close_fd[1].  Now that __close_fd has been renamed close_fd, rename
close_fd_get_file to be consistent with close_fd.

When __alloc_fd, __close_fd and __fd_install were introduced the
double underscore indicated that the function took a struct
files_struct parameter.  The function __close_fd_get_file never has so
the naming has always been inconsistent.  This just cleans things up
so there are not any lingering mentions or references __close_fd left
in the code.

[1] 80cd7956 ("binder: fix use-after-free due to ksys_close() during fdget()")
Link: https://lkml.kernel.org/r/20201120231441.29911-23-ebiederm@xmission.comSigned-off-by: NEric W. Biederman <ebiederm@xmission.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-6.0
commit 9a1aac8a
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I6FY06
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a1aac8a96dc014bec49806a7a964bf2fdbd315f

Intel-SIG: commit 9a1aac8a platform/x86: ISST: PUNIT device mapping
with Sub-NUMA clustering.
Backport for intel SST feature sub-NUMA bug fix

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

On a multiple package system using Sub-NUMA clustering, there is an issue
in mapping Linux CPU number to PUNIT PCI device when manufacturer decided
to reuse the PCI bus number across packages. Bus number can be reused as
long as they are in different domain or segment. In this case some CPU
will fail to find a PCI device to issue SST requests.

When bus numbers are reused across CPU packages, we are using proximity
information by matching CPU numa node id to PUNIT PCI device numa node
id. But on a package there can be only one PUNIT PCI device, but multiple
numa nodes (one for each sub cluster). So, the numa node ID of the PUNIT
PCI device can only match with one numa node id of CPUs in a sub cluster
in the package.

Since there can be only one PUNIT PCI device per package, if we match
with numa node id of any sub cluster in that package, we can use that
mapping for any CPU in that package. So, store the match information
in a per package data structure and return the information when there
is no match.

While here, use defines for max bus number instead of hardcoding.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://lore.kernel.org/r/20220629194817.2418240-1-srinivas.pandruvada@linux.intel.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: Nyingbao jia <yingbao.jia@intel.com>

mainline inclusion
from mainline-5.15
commit 55879dc4
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I6FY06
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=55879dc4d095232609fe81498c1b43f042708eef

Intel-SIG: commit 55879dc4 platform/x86: ISST: use semi-colons
instead of commas.
Backport SST missed patch for 5.10.

-------------------------------------------------
The code works the same either way, but it's better to use semi-colons
to separate statements.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20210825072357.GA12957@kiliSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: Nyingbao jia <yingbao.jia@intel.com>

commit 0cd3f561 upstream.
mainline inclusion
from mainline-5.11
commit 0cd3f561
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I6FY06
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0cd3f561efa9adce840140720e0581355db3e554

Intel-SIG: commit 0cd3f561 platform/x86: ISST: Mark mmio_range_devid_0
and mmio_range_devid_1 with static keyword.
Backport SST missed patch for 5.10.

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

Fix the following sparse warnings:

drivers/platform/x86/intel_speed_select_if/isst_if_mmio.c:23:24: warning: symbol 'mmio_range_devid_0' was not declared. Should it be static?
drivers/platform/x86/intel_speed_select_if/isst_if_mmio.c:28:24: warning: symbol 'mmio_range_devid_1' was not declared. Should it be static?
Signed-off-by: NZou Wei <zou_wei@huawei.com>
Link: https://lore.kernel.org/r/1607430489-116200-1-git-send-email-zou_wei@huawei.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: Nyingbao jia <yingbao.jia@intel.com>

mainline inclusion
from mainline-5.11
commit 7c88ab57
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I6FY06
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7c88ab5715a265d5dde06e4e1b0dd4370d911372

Intel-SIG: commit 7c88ab57 platform/x86: ISST: Change PCI device macros.
Backport SST missed patch for 5.10.

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

Use PCI_VDEVICE and PCI_DEVICE_DATA macros. No functional changes are
expected.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://lore.kernel.org/r/20201204015746.1168941-3-srinivas.pandruvada@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: Nyingbao jia <yingbao.jia@intel.com>

mainline inclusion
from mainline-5.11
commit 761f0ee0
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I6FY06
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=761f0ee0e84b4c18535c6d17890ccc9f5c617e8d

Intel-SIG: commit 761f0ee0 platform/x86: ISST: Allow configurable
offset range.
Backport SST missed patch for 5.10.

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

The mmio offset range can be different based on the PCI device id. Here
for INTEL_RAPL_PRIO_DEVID_1, the range is increased from 45 to 64. Pass
the range as the driver_data. Also account for different ranges during
save/restore via suspend/resume callbacks.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://lore.kernel.org/r/20201204015746.1168941-2-srinivas.pandruvada@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: Nyingbao jia <yingbao.jia@intel.com>

mainline inclusion
from mainline-5.11
commit a552f204
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I6FY06
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a552f204b050b213b1e41a5134a0d2726c9a2ec1

Intel-SIG: commit a552f204 platform/x86: ISST: Check for unaligned
mmio address.
Backport SST missed patch for 5.10.

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

The address should be aligned to 4 byte boundary. So send an error for
unaligned address.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://lore.kernel.org/r/20201204015746.1168941-1-srinivas.pandruvada@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: Nyingbao jia <yingbao.jia@intel.com>

mainline inclusion
from mainline-5.15
commit d36d4a1d
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I6FY06
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d36d4a1d75d2a8bd14ec00d5cb0ce166f6886146

Intel-SIG: commit d36d4a1d platform/x86: ISST: Fix optimization with use of numa.
Backport for ISST driver fix

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

When numa is used to map CPU to PCI device, the optimized path to read
from cached data is not working and still calls _isst_if_get_pci_dev().

The reason is that when caching the mapping, numa information is not
available as it is read later. So move the assignment of
isst_cpu_info[cpu].numa_node before calling _isst_if_get_pci_dev().

Fixes: aa2ddd24 ("platform/x86: ISST: Use numa node id for cpu pci dev mapping")
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://lore.kernel.org/r/20210727165052.427238-1-srinivas.pandruvada@linux.intel.comSigned-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: Nyingbao jia <yingbao.jia@intel.com>

mainline inclusion
from mainline-5.14
commit aa2ddd24
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I6FY06
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa2ddd24257213bdfd2f65058531810ac57455dc

Intel-SIG: commit aa2ddd24 platform/x86: ISST: Use numa node id
for cpu pci dev mapping.
Backport for ISST Optimize PCI device mapping

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

There is a problem in mapping CPU to a PCI device instance when the
bus numbers are reused in different packages. This was observed on
some Sapphire Rapids systems.

The current implementation reads bus number assigned to a CPU package
via MSR 0x128. This allows to establish relationship between a CPU
and a PCI device. This allows to update power related parameters to a
MMIO offset in a PCI device space which is unique to a CPU. But if
two packages uses same bus number then this mapping will not be unique.

When bus number is reused, PCI device will use different domain number
or segment number. So we need to be aware of this domain information
while matching CPU to PCI bus number. This domain information is not
available via any MSR. So need to use ACPI numa node information.

There is an interface already available in the Linux to read numa
node for a CPU and a PCI device. This change uses this interface
to check the numa node of a match PCI device with bus number.
If the bus number and numa node matches with the CPU's assigned
bus number and numa node, the matched PCI device instance will be
returned to the caller.

It is possible that before Sapphire Rapids, the numa node is not
defined for the Speed Select PCI device in some OEM systems. In this
case to restore old behavior, return the last matched PCI device
for domain 0 unlsess there are more than one matches.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://lore.kernel.org/r/20210616221329.1909276-2-srinivas.pandruvada@linux.intel.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: Nyingbao jia <yingbao.jia@intel.com>

mainline inclusion
from mainline-5.14
commit 1e42de8e
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I6FY06
CVE: NA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e42de8e53d32bbd7a732df49d872a30b4f888b4

Intel-SIG: commit 1e42de8e platform/x86: ISST: Optimize CPU to PCI
device mapping.
Backport for ISST Optimize PCI device mapping

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

It was observed that some of the high performance benchmarks are spending
more time in kernel depending on which CPU package they are executing.
The difference is significant and benchmark scores varies more than 10%.
These benchmarks adjust class of service to improve thread performance
which run in parallel. This class of service change causes access to
MMIO region of Intel Speed Select PCI devices depending on the CPU
package they are executing.

This mapping from CPU to PCI device instance uses a standard Linux PCI
interface "pci_get_domain_bus_and_slot()". This function does a linear
search to get to a PCI device. Since these platforms have 100+ PCI
devices, this search can be expensive in fast path for benchmarks.

Since the device and function of PCI device is fixed for Intel
Speed Select PCI devices, the CPU to PCI device information can be cached
at the same time when bus number for the CPU is read. In this way during
runtime the cached information can be used. This improves performance
of these benchmarks significantly.
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Link: https://lore.kernel.org/r/20210616221329.1909276-1-srinivas.pandruvada@linux.intel.comReviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: Nyingbao jia <yingbao.jia@intel.com>

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

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

The BMA software is a system management software offered by Huawei.
It supports the status monitoring, performance monitoring and
event monitoring of various components, including server CPUs,
memory hard disks, NICs, IB cards, PCIe cards,
RAID controller cards and optical modules.

In this version, the system resets due to the BMA spin lock
when the memory usage is too high, the vulnerability has been rectified.
Signed-off-by: NHuajingjing <huajingjing1@huawei.com>
Reviewed-by: NChenJiesong <chenjiesong@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

virt inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6FHYK
CVE: NA

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

For security purposes, kvzalloc is used to allocate memory. Because
the memory may be allocated by vmalloc. So we replace kfree with
kvfree here.
Reported-by: NZhaolong Wang <wangzhaolong1@huawei.com>
Signed-off-by: NKunkun Jiang <jiangkunkun@huawei.com>
Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

virt inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6FHYK
CVE: NA

Reference: https://github.com/torvalds/linux/commit/2bed2ced40c97b8540ff38df0149e8ecb2bf4c65

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

[ Upstream commit 2bed2ced ]

Variables allocated by kvzalloc should not be freed by kfree.
Because they may be allocated by vmalloc.
So we replace kfree with kvfree here.

Fixes: d6a4c185 ("vfio iommu: Implementation of ioctl for dirty pages tracking")
Signed-off-by: NJiacheng Shi <billsjc@sjtu.edu.cn>
Link: https://lore.kernel.org/r/20211212091600.2560-1-billsjc@sjtu.edu.cnSigned-off-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NKunkun Jiang <jiangkunkun@huawei.com>
Reviewed-by: NKeqian Zhu <zhukeqian1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>