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

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

Add extend interface support for read and write
phy register with page. Sofar it supports only
Phy RTL8211 and YT8521.
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

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

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

The patch supports the configuration of the position indicator and
error indicator modes.
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

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

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

The patch provides a customized interface to modify the MAC mode.
Signed-off-by: Nwangpeiyang <wangpeiyang1@huawei.com>
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

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

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

This patch add support to get port wire type.
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

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

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

When the link status of the PF network port changes from up to down,
the IMP can quickly report the link down fault cause based on the
link status. If the hardware is faulty from the beginning and the
link is not up, the IMP does not report the link down event
because the status is not changed.

Therefore, an interface is provided to detect port faults.
Signed-off-by: NJie Wang <wangjie125@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

Merge Pull Request from: @svishen 
 
The PR incorporates the customization code framework to support hns3 customization requirements. The following functions are supported:

1.add support modified tx timeout
2.add support query the presence of optical module
3.add supports configure optical module enable
4.add support config and query serdes lane status
5.add support disable nic clock
6.support set pfc pause trans time
7.disbable pfc en before the reset
8.add build check in hclge_get_vf_isolate_bitmap
9.notify specified VF for recovery operation

issue:
https://gitee.com/openeuler/kernel/issues/I6W94W 
 
Link:https://gitee.com/openeuler/kernel/pulls/611 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @xia-bing1 
 
SATA disks do not support multiple hosts at the same time. When the same disk is dually connected after power-on, the host that connects to the disk reports an I/O error, which triggers the disk PHY to be disabled.
Solution:
The open-source Hisisas rolls back these policies without disabling the hard disk PHY. 
 
Link:https://gitee.com/openeuler/kernel/pulls/503 

Reviewed-by: Yihang Li <liyihang9@huawei.com> 
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @lujunhuaHW 
 

PCI: Support BAR sizes up to 8TB：
Current kernel reports that BARs larger than 128GB, e.g., this 4TB BAR, are disabled: pci 0000:01:00.0: disabling BAR 4: [mem 0x00000000-0x3ffffffffff 64bit pref] (bad alignment 0x40000000000)
Increase the maximum BAR size from 128GB to 8TB for future expansion.

Detailed Description: 
The 1813 EP device requires 4 TB BAR space to meet the address requirements on the card side. A certain amount of space is reserved for future expansion. The space is increased to 8 TB.
 
 
Link:https://gitee.com/openeuler/kernel/pulls/600 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

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

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

In that commit, if the softreset fails upon certain conditions, just
disable the PHY associated with the disk. The user needs to restore the
PHY.

SATA disks do not support simultaneous connection of multiple hosts.
Therefore, when multiple controllers are connected to a SATA disk at the
same time, the controller which is connected later failed to issue an ATA
softreset to the SATA disk. As a result, the PHY associated with the disk
is disabled and cannot be automatically recovered.

Now that, we will not focus on the execution result of softreset. No
matter whether the execution is successful or not, we will directly carry
out I_T_nexus_reset.

Fixes: c723ada8 ("scsi: hisi_sas: Disable SATA disk phy for severe I_T nexus reset failure")
Signed-off-by: NYihang Li <liyihang9@huawei.com>
Signed-off-by: Nxiabing <xiabing12@h-partners.com>

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

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

Currently hns3 driver supports vf fault detect feature. Several ras caused
by VF resources don't need to do PF function reset for recovery. The driver
only needs to notify specified VF to do reset.

So this patch use VF reset notification API for recovery.
Signed-off-by: NJie Wang <wangjie125@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

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

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

This patch adds a build check to guarantee enum value and avoid future
issues.
Signed-off-by: NJie Wang <wangjie125@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

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

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

To prevent the system from abnormally sending PFC frames after an
abnormal reset. If the reset type is not imp reset or global reset,
the system notifies the firmware to disable pfc before the reset.
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

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

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

The patch provides a customized interface to modify the pause trans time
and retains the configured parameters.
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

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

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

The patch disables the clocks of the PPP, PPU, IGU_EGU, ROCE, and
TM modules by configuring the network subctrl register.
Signed-off-by: NTian Jiang <jiangtian6@h-partners.com>
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

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

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

The patch supports the function of disabling and status query of lane
channels on a port. The patch traverses all covered lanes on the
port and powers off the serdes ds power.
Signed-off-by: NTian Jiang <jiangtian6@h-partners.com>
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

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

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

The patch provides an interface for enabling or disabling
the optical module.
Signed-off-by: NTian Jiang <jiangtian6@h-partners.com>
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

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

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

The patch provides an interface to check whether the optical module
is inserted.
Signed-off-by: NTian Jiang <jiangtian6@h-partners.com>
Signed-off-by: Nshaojijie <shaojijie@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

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

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

The patch provides a customized interface to modify the tx timeout.
Signed-off-by: NHao Chen <chenhao418@huawei.com>
Signed-off-by: NJiantao Xiao <xiaojiantao1@h-partners.com>

mainline inclusion
from mainline-v5.18-rc1
commit 3dc8a1f6
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6XOIU
CVE: NA

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

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

Current kernel reports that BARs larger than 128GB, e.g., this 4TB BAR, are
disabled:

    pci 0000:01:00.0: disabling BAR 4: [mem 0x00000000-0x3ffffffffff 64bit pref] (bad alignment 0x40000000000)

Increase the maximum BAR size from 128GB to 8TB for future expansion.

[bhelgaas: commit log]
Link: https://lore.kernel.org/r/20220118092117.10089-1-liudongdong3@huawei.comSigned-off-by: NDongdong Liu <liudongdong3@huawei.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Nhuangfangrun <huangfangrun1@h-partners.com>

Merge Pull Request from: @stinft 
 
Support SVE DWQE to increase the performance of SoC.
#I6VLLM 
 
Link:https://gitee.com/openeuler/kernel/pulls/581 

Reviewed-by: Chengchang Tang <tangchengchang@huawei.com> 
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from:  Wei Li <liwei391@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/UNWNKYXBCMVT2QIU4QPROMO5UMGXKQS7/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/585 

Reviewed-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

stable inclusion
from stable-v5.10.173
commit abfed855f05863d292de2d0ebab4656791bab9c8
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6V7TU
CVE: CVE-2023-1998

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

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

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>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/rdma-core/issues/I6VLLM

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

Added SVE DWQE flag to control libhns SVE DWQE function.
Signed-off-by: NYixing Liu <liuyixing1@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>

Merge Pull Request from: @zhangjialin11 
 
Pull new CVEs:
CVE-2023-1859
CVE-2023-1670
CVE-2023-1611

net bugfixes from Ziyang Xuan
ubi bugfixes from ZhaoLong Wang
ftrace and ring-buffer bugfixes from Zheng Yejian
perf bugfix from Yang Jihong
loop bugfix from Zhong Jinghua
ext4 bugfixes from Zhihao Cheng
dm crypt bugfix from yangerkun
driver core bugfixes from Zhang Zekun
xfs bugfixes from Long Li 
 
Link:https://gitee.com/openeuler/kernel/pulls/575 

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

Merge Pull Request from: @stinft 
 
```bash
Feature information:
1.RDMA/hns: Modify congestion abbreviation
The currently used abbreviation of cong cannot clearly
indicate the meaning, so the full name congest is used instead.

2.RDMA/hns: Support congestion control algorithm configuration at QP granularity
This patch supports to configure congestion control algorithm
based on QP granulariy. The configuration will be sent to
driver from user space. And then driver configures the selected
algorithm into QPC.
The current XRC type QP cannot deliver the configured
algorithm to kernel space, so the driver will set the default
algorithm for XRC type QP. And the default algorithm type is
controlled by the firmware.
```
bugzilla：#I6N1G4
 
 
Link:https://gitee.com/openeuler/kernel/pulls/576 

Reviewed-by: Chengchang Tang <tangchengchang@huawei.com> 
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @hellotcc 
 
Add Kunpeng SoC maintainers to openEuler/MAINTAINERS. 
 
Link:https://gitee.com/openeuler/kernel/pulls/424 

Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> 
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com> 

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6N1G4

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

This patch supports to configure congestion control algorithm
based on QP granulariy. The configuration will be sent to
driver from user space. And then driver configures the selected
algorithm into QPC.

The current XRC type QP cannot deliver the configured
algorithm to kernel space, so the driver will set the default
algorithm for XRC type QP. And the default algorithm type is
controlled by the firmware.
Signed-off-by: NYixing Liu <liuyixing1@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>

driver inclusion
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I6N1G4

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

The currently used abbreviation of cong cannot clearly
indicate the meaning, so the full name congest is used instead.
Signed-off-by: NYixing Liu <liuyixing1@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>

mainline inclusion
from mainline-v6.2-rc1
commit 6431b0f6
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TPN9
CVE: NA

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

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

After commit d38afeec ("tcp/udp: Call inet6_destroy_sock()
in IPv6 sk->sk_destruct()."), we call inet6_destroy_sock() in
sk->sk_destruct() by setting inet6_sock_destruct() to it to make
sure we do not leak inet6-specific resources.

SCTP sets its own sk->sk_destruct() in the sctp_init_sock(), and
SCTPv6 socket reuses it as the init function.

To call inet6_sock_destruct() from SCTPv6 sk->sk_destruct(), we
set sctp_v6_destruct_sock() in a new init function.
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.2-rc1
commit 1651951e
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TPN9
CVE: NA

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

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

After commit d38afeec ("tcp/udp: Call inet6_destroy_sock()
in IPv6 sk->sk_destruct()."), we call inet6_destroy_sock() in
sk->sk_destruct() by setting inet6_sock_destruct() to it to make
sure we do not leak inet6-specific resources.

DCCP sets its own sk->sk_destruct() in the dccp_init_sock(), and
DCCPv6 socket shares it by calling the same init function via
dccp_v6_init_sock().

To call inet6_sock_destruct() from DCCPv6 sk->sk_destruct(), we
export it and set dccp_v6_sk_destruct() in the init function.
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.171
commit 3e4bbd1f38a8d35bd2d3aaffdb5f6ada546b669a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TPN9
CVE: NA

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

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

commit 62ec33b4 upstream.

Christoph Paasch reported that commit b5fc2923 ("inet6: Remove
inet6_destroy_sock() in sk->sk_prot->destroy().") started triggering
WARN_ON_ONCE(sk->sk_forward_alloc) in sk_stream_kill_queues().  [0 - 2]
Also, we can reproduce it by a program in [3].

In the commit, we delay freeing ipv6_pinfo.pktoptions from sk->destroy()
to sk->sk_destruct(), so sk->sk_forward_alloc is no longer zero in
inet_csk_destroy_sock().

The same check has been in inet_sock_destruct() from at least v2.6,
we can just remove the WARN_ON_ONCE().  However, among the users of
sk_stream_kill_queues(), only CAIF is not calling inet_sock_destruct().
Thus, we add the same WARN_ON_ONCE() to caif_sock_destructor().

[0]: https://lore.kernel.org/netdev/39725AB4-88F1-41B3-B07F-949C5CAEFF4F@icloud.com/
[1]: https://github.com/multipath-tcp/mptcp_net-next/issues/341
[2]:
WARNING: CPU: 0 PID: 3232 at net/core/stream.c:212 sk_stream_kill_queues+0x2f9/0x3e0
Modules linked in:
CPU: 0 PID: 3232 Comm: syz-executor.0 Not tainted 6.2.0-rc5ab24eb4698afbe147b424149c529e2a43ec24eb5 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:sk_stream_kill_queues+0x2f9/0x3e0
Code: 03 0f b6 04 02 84 c0 74 08 3c 03 0f 8e ec 00 00 00 8b ab 08 01 00 00 e9 60 ff ff ff e8 d0 5f b6 fe 0f 0b eb 97 e8 c7 5f b6 fe <0f> 0b eb a0 e8 be 5f b6 fe 0f 0b e9 6a fe ff ff e8 02 07 e3 fe e9
RSP: 0018:ffff88810570fc68 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff888101f38f40 RSI: ffffffff8285e529 RDI: 0000000000000005
RBP: 0000000000000ce0 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000ce0 R11: 0000000000000001 R12: ffff8881009e9488
R13: ffffffff84af2cc0 R14: 0000000000000000 R15: ffff8881009e9458
FS:  00007f7fdfbd5800(0000) GS:ffff88811b600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32923000 CR3: 00000001062fc006 CR4: 0000000000170ef0
Call Trace:
 <TASK>
 inet_csk_destroy_sock+0x1a1/0x320
 __tcp_close+0xab6/0xe90
 tcp_close+0x30/0xc0
 inet_release+0xe9/0x1f0
 inet6_release+0x4c/0x70
 __sock_release+0xd2/0x280
 sock_close+0x15/0x20
 __fput+0x252/0xa20
 task_work_run+0x169/0x250
 exit_to_user_mode_prepare+0x113/0x120
 syscall_exit_to_user_mode+0x1d/0x40
 do_syscall_64+0x48/0x90
 entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x7f7fdf7ae28d
Code: c1 20 00 00 75 10 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 ee fb ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 37 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:00000000007dfbb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000004 RCX: 00007f7fdf7ae28d
RDX: 0000000000000000 RSI: ffffffffffffffff RDI: 0000000000000003
RBP: 0000000000000000 R08: 000000007f338e0f R09: 0000000000000e0f
R10: 000000007f338e13 R11: 0000000000000293 R12: 00007f7fdefff000
R13: 00007f7fdefffcd8 R14: 00007f7fdefffce0 R15: 00007f7fdefffcd8
 </TASK>

[3]: https://lore.kernel.org/netdev/20230208004245.83497-1-kuniyu@amazon.com/

Fixes: b5fc2923 ("inet6: Remove inet6_destroy_sock() in sk->sk_prot->destroy().")
Reported-by: Nsyzbot <syzkaller@googlegroups.com>
Reported-by: NChristoph Paasch <christophpaasch@icloud.com>
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.2-rc1
commit b5fc2923
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TPN9
CVE: NA

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

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

After commit d38afeec ("tcp/udp: Call inet6_destroy_sock()
in IPv6 sk->sk_destruct()."), we call inet6_destroy_sock() in
sk->sk_destruct() by setting inet6_sock_destruct() to it to make
sure we do not leak inet6-specific resources.

Now we can remove unnecessary inet6_destroy_sock() calls in
sk->sk_prot->destroy().

DCCP and SCTP have their own sk->sk_destruct() function, so we
change them separately in the following patches.
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: NMatthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Conflicts:
	net/ipv6/ping.c
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

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

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

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

Originally, inet6_sk(sk)->XXX were changed under lock_sock(), so we were
able to clean them up by calling inet6_destroy_sock() during the IPv6 ->
IPv4 conversion by IPV6_ADDRFORM.  However, commit 03485f2a ("udpv6:
Add lockless sendmsg() support") added a lockless memory allocation path,
which could cause a memory leak:

setsockopt(IPV6_ADDRFORM)                 sendmsg()
+-----------------------+                 +-------+
- do_ipv6_setsockopt(sk, ...)             - udpv6_sendmsg(sk, ...)
  - sockopt_lock_sock(sk)                   ^._ called via udpv6_prot
    - lock_sock(sk)                             before WRITE_ONCE()
  - WRITE_ONCE(sk->sk_prot, &tcp_prot)
  - inet6_destroy_sock()                    - if (!corkreq)
  - sockopt_release_sock(sk)                  - ip6_make_skb(sk, ...)
    - release_sock(sk)                          ^._ lockless fast path for
                                                    the non-corking case

                                                - __ip6_append_data(sk, ...)
                                                  - ipv6_local_rxpmtu(sk, ...)
                                                    - xchg(&np->rxpmtu, skb)
                                                      ^._ rxpmtu is never freed.

                                                - goto out_no_dst;

                                            - lock_sock(sk)

For now, rxpmtu is only the case, but not to miss the future change
and a similar bug fixed in commit e2732600 ("net: ping6: Fix
memleak in ipv6_renew_options()."), let's set a new function to IPv6
sk->sk_destruct() and call inet6_cleanup_sock() there.  Since the
conversion does not change sk->sk_destruct(), we can guarantee that
we can clean up IPv6 resources finally.

We can now remove all inet6_destroy_sock() calls from IPv6 protocol
specific ->destroy() functions, but such changes are invasive to
backport.  So they can be posted as a follow-up later for net-next.

Fixes: 03485f2a ("udpv6: Add lockless sendmsg() support")
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.1-rc1
commit 21985f43
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TPN9
CVE: NA

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

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

Commit 4b340ae2 ("IPv6: Complete IPV6_DONTFRAG support") forgot
to add a change to free inet6_sk(sk)->rxpmtu while converting an IPv6
socket into IPv4 with IPV6_ADDRFORM.  After conversion, sk_prot is
changed to udp_prot and ->destroy() never cleans it up, resulting in
a memory leak.

This is due to the discrepancy between inet6_destroy_sock() and
IPV6_ADDRFORM, so let's call inet6_destroy_sock() from IPV6_ADDRFORM
to remove the difference.

However, this is not enough for now because rxpmtu can be changed
without lock_sock() after commit 03485f2a ("udpv6: Add lockless
sendmsg() support").  We will fix this case in the following patch.

Note we will rename inet6_destroy_sock() to inet6_cleanup_sock() and
remove unnecessary inet6_destroy_sock() calls in sk_prot->destroy()
in the future.

Fixes: 4b340ae2 ("IPv6: Complete IPV6_DONTFRAG support")
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

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: NJialin Zhang <zhangjialin11@huawei.com>

maillist inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6U6XK

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

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

Following process will make ubi attaching failed since commit
1b42b1a3 ("ubi: ensure that VID header offset ... size"):

ID="0xec,0xa1,0x00,0x15" # 128M 128KB 2KB
modprobe nandsim id_bytes=$ID
flash_eraseall /dev/mtd0
modprobe ubi mtd="0,2048"  # set vid_hdr offset as 2048 (one page)
(dmesg):
  ubi0 error: ubi_attach_mtd_dev [ubi]: VID header offset 2048 too large.
  UBI error: cannot attach mtd0
  UBI error: cannot initialize UBI, error -22

Rework original solution, the key point is making sure
'vid_hdr_shift + UBI_VID_HDR_SIZE < ubi->vid_hdr_alsize',
so we should check vid_hdr_shift rather not vid_hdr_offset.
Then, ubi still support (sub)page aligined VID header offset.

Fixes: 1b42b1a3 ("ubi: ensure that VID header offset ... size")
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
Tested-by: NNicolas Schichan <nschichan@freebox.fr>
Tested-by: Miquel Raynal <miquel.raynal@bootlin.com> # v5.10, v4.19
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.173
commit 846bfba34175c23b13cc2023c2d67b96e8c14c43
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6PMQI

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

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

[ Upstream commit 1b42b1a3 ]

Ensure that the VID header offset + VID header size does not exceed
the allocated area to avoid slab OOB.

BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197
Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555

CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G        W
6.0.0-1868 #1
Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29
04/01/2014
Call Trace:
  <TASK>
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x85/0xad lib/dump_stack.c:106
  print_address_description mm/kasan/report.c:317 [inline]
  print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433
  kasan_report+0xa7/0x11b mm/kasan/report.c:495
  crc32_body lib/crc32.c:111 [inline]
  crc32_le_generic lib/crc32.c:179 [inline]
  crc32_le_base+0x58c/0x626 lib/crc32.c:197
  ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c:1067
  create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317
  create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]
  ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812
  ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601
  ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965
  ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043
  vfs_ioctl fs/ioctl.c:51 [inline]
  __do_sys_ioctl fs/ioctl.c:870 [inline]
  __se_sys_ioctl fs/ioctl.c:856 [inline]
  __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856
  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
  do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80
  entry_SYSCALL_64_after_hwframe+0x63/0x0
RIP: 0033:0x7f96d5cf753d
Code:
RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d
RDX: 0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003
RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0
R13: 00007fffd72207e0 R14: 0000000000000000 R15: 0000000000000000
  </TASK>

Allocated by task 1555:
  kasan_save_stack+0x20/0x3d mm/kasan/common.c:38
  kasan_set_track mm/kasan/common.c:45 [inline]
  set_alloc_info mm/kasan/common.c:437 [inline]
  ____kasan_kmalloc mm/kasan/common.c:516 [inline]
  __kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525
  kasan_kmalloc include/linux/kasan.h:234 [inline]
  __kmalloc+0x138/0x257 mm/slub.c:4429
  kmalloc include/linux/slab.h:605 [inline]
  ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline]
  create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295
  create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]
  ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812
  ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601
  ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965
  ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043
  vfs_ioctl fs/ioctl.c:51 [inline]
  __do_sys_ioctl fs/ioctl.c:870 [inline]
  __se_sys_ioctl fs/ioctl.c:856 [inline]
  __x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856
  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
  do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80
  entry_SYSCALL_64_after_hwframe+0x63/0x0

The buggy address belongs to the object at ffff88802bb36e00
  which belongs to the cache kmalloc-256 of size 256
The buggy address is located 0 bytes to the right of
  256-byte region [ffff88802bb36e00, ffff88802bb36f00)

The buggy address belongs to the physical page:
page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000
index:0x0 pfn:0x2bb36
head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0
flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
raw: 000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
  ffff88802bb36e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  ffff88802bb36e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff88802bb36f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                    ^
  ffff88802bb36f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
  ffff88802bb37000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

Fixes: 801c135c ("UBI: Unsorted Block Images")
Reported-by: Nsyzkaller <syzkaller@googlegroups.com>
Signed-off-by: NGeorge Kennedy <george.kennedy@oracle.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NWang Hai <wanghai38@huawei.com>
Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.3-rc6
commit 2a2d8c51
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6TQ89
CVE: NA

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

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

Syzkaller report a WARNING: "WARN_ON(!direct)" in modify_ftrace_direct().

Root cause is 'direct->addr' was changed from 'old_addr' to 'new_addr' but
not restored if error happened on calling ftrace_modify_direct_caller().
Then it can no longer find 'direct' by that 'old_addr'.

To fix it, restore 'direct->addr' to 'old_addr' explicitly in error path.

Link: https://lore.kernel.org/linux-trace-kernel/20230330025223.1046087-1-zhengyejian1@huawei.com

Cc: stable@vger.kernel.org
Cc: <mhiramat@kernel.org>
Cc: <mark.rutland@arm.com>
Cc: <ast@kernel.org>
Cc: <daniel@iogearbox.net>
Fixes: 77ab7785 ("ftrace: Fix modify_ftrace_direct.")
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Signed-off-by: NSteven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.3-rc3
commit eb81a2ed
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6ODHQ
CVE: NA

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

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

syzkaller reportes a KASAN issue with stack-out-of-bounds.
The call trace is as follows:
  dump_stack+0x9c/0xd3
  print_address_description.constprop.0+0x19/0x170
  __kasan_report.cold+0x6c/0x84
  kasan_report+0x3a/0x50
  __perf_event_header__init_id+0x34/0x290
  perf_event_header__init_id+0x48/0x60
  perf_output_begin+0x4a4/0x560
  perf_event_bpf_output+0x161/0x1e0
  perf_iterate_sb_cpu+0x29e/0x340
  perf_iterate_sb+0x4c/0xc0
  perf_event_bpf_event+0x194/0x2c0
  __bpf_prog_put.constprop.0+0x55/0xf0
  __cls_bpf_delete_prog+0xea/0x120 [cls_bpf]
  cls_bpf_delete_prog_work+0x1c/0x30 [cls_bpf]
  process_one_work+0x3c2/0x730
  worker_thread+0x93/0x650
  kthread+0x1b8/0x210
  ret_from_fork+0x1f/0x30

commit 267fb273 ("perf: Reduce stack usage of perf_output_begin()")
use on-stack struct perf_sample_data of the caller function.

However, perf_event_bpf_output uses incorrect parameter to convert
small-sized data (struct perf_bpf_event) into large-sized data
(struct perf_sample_data), which causes memory overwriting occurs in
__perf_event_header__init_id.

Fixes: 267fb273 ("perf: Reduce stack usage of perf_output_begin()")
Signed-off-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20230314044735.56551-1-yangjihong1@huawei.comSigned-off-by: NYang Jihong <yangjihong1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NZheng Yejian <zhengyejian1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.176
commit bfeeb3aaad4ee8eaaefe5d9edd9b2ccb5d9b7505
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=bfeeb3aaad4ee8eaaefe5d9edd9b2ccb5d9b7505

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

[ 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: NJialin Zhang <zhangjialin11@huawei.com>