Merge Pull Request from: @ci-robot 
 
PR sync from: Dong Chenchen <dongchenchen2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/SSEHK2X4FXLBNQQWQWI356DBSZU5ABK6/ 
 
https://gitee.com/src-openeuler/kernel/issues/I7SXVG 
 
Link:https://gitee.com/openeuler/kernel/pulls/1807 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Zhengchao Shao <shaozhengchao@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/G5OSD5RLARLR4R7GJ3EUB6LG6ONKAZ46/ 
 
https://gitee.com/src-openeuler/kernel/issues/I7UWI8 
 
Link:https://gitee.com/openeuler/kernel/pulls/1844 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@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/message/7CEZ6NYTS3GYYHEHIRSCXMVPIZ7PKNB4/ 
 
https://gitee.com/openeuler/kernel/issues/I7THI2 
 
Link:https://gitee.com/openeuler/kernel/pulls/1785 

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

Merge Pull Request from: @ci-robot 
 
PR sync from: Li Nan <linan122@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/YC56BN75ZGPSQ5YHGT6A54EO2N7GUO7G/ 
 
https://gitee.com/src-openeuler/kernel/issues/I7TT9F 
 
Link:https://gitee.com/openeuler/kernel/pulls/1849 

Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

mainline inclusion
from mainline-v5.19-rc1
commit 0d4837fd
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7TT9F
CVE: CVE-2023-4385

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

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

In our fault-injection testing, the variable "nblocks" in dbFree() can be
zero when kmalloc_array() fails in dtSearch(). In this case, the variable
 "mp" in dbFree() would be NULL and then it is dereferenced in
"write_metapage(mp)".

The failure log is listed as follows:

[   13.824137] BUG: kernel NULL pointer dereference, address: 0000000000000020
...
[   13.827416] RIP: 0010:dbFree+0x5f7/0x910 [jfs]
[   13.834341] Call Trace:
[   13.834540]  <TASK>
[   13.834713]  txFreeMap+0x7b4/0xb10 [jfs]
[   13.835038]  txUpdateMap+0x311/0x650 [jfs]
[   13.835375]  jfs_lazycommit+0x5f2/0xc70 [jfs]
[   13.835726]  ? sched_dynamic_update+0x1b0/0x1b0
[   13.836092]  kthread+0x3c2/0x4a0
[   13.836355]  ? txLockFree+0x160/0x160 [jfs]
[   13.836763]  ? kthread_unuse_mm+0x160/0x160
[   13.837106]  ret_from_fork+0x1f/0x30
[   13.837402]  </TASK>
...

This patch adds a NULL check of "mp" before "write_metapage(mp)" is called.
Reported-by: NTOTE Robot <oslab@tsinghua.edu.cn>
Signed-off-by: NZixuan Fu <r33s3n6@gmail.com>
Signed-off-by: NDave Kleikamp <dave.kleikamp@oracle.com>
Signed-off-by: NLi Nan <linan122@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Wang Yufen <wangyufen@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/P3JACN4MLJW7G5NKTXBTQ46GZ5R5YEBI/ 
 
https://gitee.com/src-openeuler/kernel/issues/I7FUFX 
 
Link:https://gitee.com/openeuler/kernel/pulls/1836 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

mainline inclusion
from mainline-v5.18-rc1
commit edf410cb
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7UWI8
CVE: CVE-2023-4459

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

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

In vmxnet3_rq_create(), when dma_alloc_coherent() fails,
vmxnet3_rq_destroy() is called. It sets rq->rx_ring[i].base to NULL. Then
vmxnet3_rq_create() returns an error to its callers mxnet3_rq_create_all()
-> vmxnet3_change_mtu(). Then vmxnet3_change_mtu() calls
vmxnet3_force_close() -> dev_close() in error handling code. And the driver
calls vmxnet3_close() -> vmxnet3_quiesce_dev() -> vmxnet3_rq_cleanup_all()
-> vmxnet3_rq_cleanup(). In vmxnet3_rq_cleanup(),
rq->rx_ring[ring_idx].base is accessed, but this variable is NULL, causing
a NULL pointer dereference.

To fix this possible bug, an if statement is added to check whether
rq->rx_ring[0].base is NULL in vmxnet3_rq_cleanup() and exit early if so.

The error log in our fault-injection testing is shown as follows:

[   65.220135] BUG: kernel NULL pointer dereference, address: 0000000000000008
...
[   65.222633] RIP: 0010:vmxnet3_rq_cleanup_all+0x396/0x4e0 [vmxnet3]
...
[   65.227977] Call Trace:
...
[   65.228262]  vmxnet3_quiesce_dev+0x80f/0x8a0 [vmxnet3]
[   65.228580]  vmxnet3_close+0x2c4/0x3f0 [vmxnet3]
[   65.228866]  __dev_close_many+0x288/0x350
[   65.229607]  dev_close_many+0xa4/0x480
[   65.231124]  dev_close+0x138/0x230
[   65.231933]  vmxnet3_force_close+0x1f0/0x240 [vmxnet3]
[   65.232248]  vmxnet3_change_mtu+0x75d/0x920 [vmxnet3]
...

Fixes: d1a890fa ("net: VMware virtual Ethernet NIC driver: vmxnet3")
Reported-by: NTOTE Robot <oslab@tsinghua.edu.cn>
Signed-off-by: NZixuan Fu <r33s3n6@gmail.com>
Link: https://lore.kernel.org/r/20220514050711.2636709-1-r33s3n6@gmail.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Zhengchao Shao <shaozhengchao@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/SSI5KSNIBIND62KVZGNOMSAFARHCSUFY/ 
When nf_nat_ipv4.ko is not loaded, l3proto is NULL pointer. If the
csum_recalc function of l3proto is called, it will cause NULL pointer
access issue.

---
v3: add space after return type for Patch 3/3
v2: modify commit message for Patch 3/3
---

Florian Westphal (2):
  netfilter: nat: remove csum_recalc hook
  netfilter: nat: fix udp checksum corruption

Zhengchao Shao (1):
  netfilter: nat: fix kabi change


-- 
2.34.1
 
https://gitee.com/openeuler/kernel/issues/I7O0PV 
 
Link:https://gitee.com/openeuler/kernel/pulls/1831 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

stable inclusion
from stable-v4.19.291
commit d11b0df7ddf1831f3e170972f43186dad520bfcc
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7FUFX
CVE: CVE-2023-1206

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

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

[ Upstream commit d11b0df7ddf1831f3e170972f43186dad520bfcc ]

For both IPv4 and IPv6 incoming TCP connections are tracked in a hash
table with a hash over the source & destination addresses and ports.
However, the IPv6 hash is insufficient and can lead to a high rate of
collisions.

The IPv6 hash used an XOR to fit everything into the 96 bits for the
fast jenkins hash, meaning it is possible for an external entity to
ensure the hash collides, thus falling back to a linear search in the
bucket, which is slow.

We take the approach of hash the full length of IPv6 address in
__ipv6_addr_jhash() so that all users can benefit from a more secure
version.

While this may look like it adds overhead, the reality of modern CPUs
means that this is unmeasurable in real world scenarios.

In simulating with llvm-mca, the increase in cycles for the hashing
code was ~16 cycles on Skylake (from a base of ~155), and an extra ~9
on Nehalem (base of ~173).

In commit dd6d2910 ("netfilter: conntrack: switch to siphash")
netfilter switched from a jenkins hash to a siphash, but even the faster
hsiphash is a more significant overhead (~20-30%) in some preliminary
testing.  So, in this patch, we keep to the more conservative approach to
ensure we don't add much overhead per SYN.

In testing, this results in a consistently even spread across the
connection buckets.  In both testing and real-world scenarios, we have
not found any measurable performance impact.

Fixes: 08dcdbf6 ("ipv6: use a stronger hash for tcp")
Signed-off-by: NStewart Smith <trawets@amazon.com>
Signed-off-by: NSamuel Mendoza-Jonas <samjonas@amazon.com>
Suggested-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20230721222410.17914-1-kuniyu@amazon.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NWang Yufen <wangyufen@huawei.com>

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

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

fix kabi change
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>

mainline inclusion
from mainline-v5.2-rc3
commit 6bac76db
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7O0PV
CVE: NA

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

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

Due to copy&paste error nf_nat_mangle_udp_packet passes IPPROTO_TCP,
resulting in incorrect udp checksum when payload had to be mangled.

Fixes: dac3fe72 ("netfilter: nat: remove csum_recalc hook")
Reported-by: NMarc Haber <mh+netdev@zugschlus.de>
Tested-by: NMarc Haber <mh+netdev@zugschlus.de>
Signed-off-by: NFlorian Westphal <fw@strlen.de>
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>

mainline inclusion
from mainline-v5.1-rc1
commit dac3fe72
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7O0PV
CVE: NA

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

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

We can now use direct calls.
Signed-off-by: NFlorian Westphal <fw@strlen.de>
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>

Conflicts:
	include/net/netfilter/nf_nat_l3proto.h
	net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
	net/ipv6/netfilter/nf_nat_l3proto_ipv6.c
	net/netfilter/Makefile
	net/netfilter/nf_nat_helper.c
	net/netfilter/nf_nat_proto.c
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Zeng Heng <zengheng4@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/VMCSQFPYZZYKFJAPUACCE3S3JB5CZCAH/ 
Lai Jiangshan (5):
  workqueue: Rename "delayed" (delayed by active management) to
    "inactive"
  workqueue: Change arguement of pwq_dec_nr_in_flight()
  workqueue: Change the code of calculating work_flags in
    insert_wq_barrier()
  workqueue: Mark barrier work with WORK_STRUCT_INACTIVE
  workqueue: Assign a color to barrier work items


--
2.25.1
 
https://gitee.com/openeuler/kernel/issues/I7LRJF 
 
Link:https://gitee.com/openeuler/kernel/pulls/1769 

Reviewed-by: Wei Li <liwei391@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Lu Wei <luwei32@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/ADZZ2NY67FCOABLLQEWR7B5IMUW7GNHN/ 
 
https://gitee.com/src-openeuler/kernel/issues/I7TTDS 
 
Link:https://gitee.com/openeuler/kernel/pulls/1803 

Reviewed-by: Liu YongQiang <liuyongqiang13@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

stable inclusion
from stable-v4.19.290
commit 82cdb2ccbe43337798393369f0ceb98699fe6037
category: bugfix
bugzilla: 189135, https://gitee.com/src-openeuler/kernel/issues/I7SXVG
CVE: CVE-2023-40283

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

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

commit 1728137b33c00d5a2b5110ed7aafb42e7c32e4a1 upstream.

l2cap_sock_release(sk) frees sk. However, sk's children are still alive
and point to the already free'd sk's address.
To fix this, l2cap_sock_release(sk) also cleans sk's children.

==================================================================
BUG: KASAN: use-after-free in l2cap_sock_ready_cb+0xb7/0x100 net/bluetooth/l2cap_sock.c:1650
Read of size 8 at addr ffff888104617aa8 by task kworker/u3:0/276

CPU: 0 PID: 276 Comm: kworker/u3:0 Not tainted 6.2.0-00001-gef397bd4d5fb-dirty #59
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: hci2 hci_rx_work
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x72/0x95 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:306 [inline]
 print_report+0x175/0x478 mm/kasan/report.c:417
 kasan_report+0xb1/0x130 mm/kasan/report.c:517
 l2cap_sock_ready_cb+0xb7/0x100 net/bluetooth/l2cap_sock.c:1650
 l2cap_chan_ready+0x10e/0x1e0 net/bluetooth/l2cap_core.c:1386
 l2cap_config_req+0x753/0x9f0 net/bluetooth/l2cap_core.c:4480
 l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:5739 [inline]
 l2cap_sig_channel net/bluetooth/l2cap_core.c:6509 [inline]
 l2cap_recv_frame+0xe2e/0x43c0 net/bluetooth/l2cap_core.c:7788
 l2cap_recv_acldata+0x6ed/0x7e0 net/bluetooth/l2cap_core.c:8506
 hci_acldata_packet net/bluetooth/hci_core.c:3813 [inline]
 hci_rx_work+0x66e/0xbc0 net/bluetooth/hci_core.c:4048
 process_one_work+0x4ea/0x8e0 kernel/workqueue.c:2289
 worker_thread+0x364/0x8e0 kernel/workqueue.c:2436
 kthread+0x1b9/0x200 kernel/kthread.c:376
 ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308
 </TASK>

Allocated by task 288:
 kasan_save_stack+0x22/0x50 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 ____kasan_kmalloc mm/kasan/common.c:374 [inline]
 __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:383
 kasan_kmalloc include/linux/kasan.h:211 [inline]
 __do_kmalloc_node mm/slab_common.c:968 [inline]
 __kmalloc+0x5a/0x140 mm/slab_common.c:981
 kmalloc include/linux/slab.h:584 [inline]
 sk_prot_alloc+0x113/0x1f0 net/core/sock.c:2040
 sk_alloc+0x36/0x3c0 net/core/sock.c:2093
 l2cap_sock_alloc.constprop.0+0x39/0x1c0 net/bluetooth/l2cap_sock.c:1852
 l2cap_sock_create+0x10d/0x220 net/bluetooth/l2cap_sock.c:1898
 bt_sock_create+0x183/0x290 net/bluetooth/af_bluetooth.c:132
 __sock_create+0x226/0x380 net/socket.c:1518
 sock_create net/socket.c:1569 [inline]
 __sys_socket_create net/socket.c:1606 [inline]
 __sys_socket_create net/socket.c:1591 [inline]
 __sys_socket+0x112/0x200 net/socket.c:1639
 __do_sys_socket net/socket.c:1652 [inline]
 __se_sys_socket net/socket.c:1650 [inline]
 __x64_sys_socket+0x40/0x50 net/socket.c:1650
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

Freed by task 288:
 kasan_save_stack+0x22/0x50 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 kasan_save_free_info+0x2e/0x50 mm/kasan/generic.c:523
 ____kasan_slab_free mm/kasan/common.c:236 [inline]
 ____kasan_slab_free mm/kasan/common.c:200 [inline]
 __kasan_slab_free+0x10a/0x190 mm/kasan/common.c:244
 kasan_slab_free include/linux/kasan.h:177 [inline]
 slab_free_hook mm/slub.c:1781 [inline]
 slab_free_freelist_hook mm/slub.c:1807 [inline]
 slab_free mm/slub.c:3787 [inline]
 __kmem_cache_free+0x88/0x1f0 mm/slub.c:3800
 sk_prot_free net/core/sock.c:2076 [inline]
 __sk_destruct+0x347/0x430 net/core/sock.c:2168
 sk_destruct+0x9c/0xb0 net/core/sock.c:2183
 __sk_free+0x82/0x220 net/core/sock.c:2194
 sk_free+0x7c/0xa0 net/core/sock.c:2205
 sock_put include/net/sock.h:1991 [inline]
 l2cap_sock_kill+0x256/0x2b0 net/bluetooth/l2cap_sock.c:1257
 l2cap_sock_release+0x1a7/0x220 net/bluetooth/l2cap_sock.c:1428
 __sock_release+0x80/0x150 net/socket.c:650
 sock_close+0x19/0x30 net/socket.c:1368
 __fput+0x17a/0x5c0 fs/file_table.c:320
 task_work_run+0x132/0x1c0 kernel/task_work.c:179
 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
 exit_to_user_mode_prepare+0x113/0x120 kernel/entry/common.c:203
 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
 syscall_exit_to_user_mode+0x21/0x50 kernel/entry/common.c:296
 do_syscall_64+0x4c/0x90 arch/x86/entry/common.c:86
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

The buggy address belongs to the object at ffff888104617800
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 680 bytes inside of
 1024-byte region [ffff888104617800, ffff888104617c00)

The buggy address belongs to the physical page:
page:00000000dbca6a80 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888104614000 pfn:0x104614
head:00000000dbca6a80 order:2 compound_mapcount:0 subpages_mapcount:0 compound_pincount:0
flags: 0x200000000010200(slab|head|node=0|zone=2)
raw: 0200000000010200 ffff888100041dc0 ffffea0004212c10 ffffea0004234b10
raw: ffff888104614000 0000000000080002 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff888104617980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888104617a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888104617a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                  ^
 ffff888104617b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888104617b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

Ack: This bug is found by FuzzBT with a modified Syzkaller. Other
contributors are Ruoyu Wu and Hui Peng.
Signed-off-by: NSungwoo Kim <iam@sung-woo.kim>
Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>

stable inclusion
from stable-v4.19.245
commit 3adaaf3472e8ea410cb1330e5dd8372b0483dc78
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7TTDS
CVE: CVE-2023-4387

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

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

[ Upstream commit 9e7fef95 ]

In vmxnet3_rq_alloc_rx_buf(), when dma_map_single() fails, rbi->skb is
freed immediately. Similarly, in another branch, when dma_map_page() fails,
rbi->page is also freed. In the two cases, vmxnet3_rq_alloc_rx_buf()
returns an error to its callers vmxnet3_rq_init() -> vmxnet3_rq_init_all()
-> vmxnet3_activate_dev(). Then vmxnet3_activate_dev() calls
vmxnet3_rq_cleanup_all() in error handling code, and rbi->skb or rbi->page
are freed again in vmxnet3_rq_cleanup_all(), causing use-after-free bugs.

To fix these possible bugs, rbi->skb and rbi->page should be cleared after
they are freed.

The error log in our fault-injection testing is shown as follows:

[   14.319016] BUG: KASAN: use-after-free in consume_skb+0x2f/0x150
...
[   14.321586] Call Trace:
...
[   14.325357]  consume_skb+0x2f/0x150
[   14.325671]  vmxnet3_rq_cleanup_all+0x33a/0x4e0 [vmxnet3]
[   14.326150]  vmxnet3_activate_dev+0xb9d/0x2ca0 [vmxnet3]
[   14.326616]  vmxnet3_open+0x387/0x470 [vmxnet3]
...
[   14.361675] Allocated by task 351:
...
[   14.362688]  __netdev_alloc_skb+0x1b3/0x6f0
[   14.362960]  vmxnet3_rq_alloc_rx_buf+0x1b0/0x8d0 [vmxnet3]
[   14.363317]  vmxnet3_activate_dev+0x3e3/0x2ca0 [vmxnet3]
[   14.363661]  vmxnet3_open+0x387/0x470 [vmxnet3]
...
[   14.367309]
[   14.367412] Freed by task 351:
...
[   14.368932]  __dev_kfree_skb_any+0xd2/0xe0
[   14.369193]  vmxnet3_rq_alloc_rx_buf+0x71e/0x8d0 [vmxnet3]
[   14.369544]  vmxnet3_activate_dev+0x3e3/0x2ca0 [vmxnet3]
[   14.369883]  vmxnet3_open+0x387/0x470 [vmxnet3]
[   14.370174]  __dev_open+0x28a/0x420
[   14.370399]  __dev_change_flags+0x192/0x590
[   14.370667]  dev_change_flags+0x7a/0x180
[   14.370919]  do_setlink+0xb28/0x3570
[   14.371150]  rtnl_newlink+0x1160/0x1740
[   14.371399]  rtnetlink_rcv_msg+0x5bf/0xa50
[   14.371661]  netlink_rcv_skb+0x1cd/0x3e0
[   14.371913]  netlink_unicast+0x5dc/0x840
[   14.372169]  netlink_sendmsg+0x856/0xc40
[   14.372420]  ____sys_sendmsg+0x8a7/0x8d0
[   14.372673]  __sys_sendmsg+0x1c2/0x270
[   14.372914]  do_syscall_64+0x41/0x90
[   14.373145]  entry_SYSCALL_64_after_hwframe+0x44/0xae
...

Fixes: 5738a09d ("vmxnet3: fix checks for dma mapping errors")
Reported-by: NTOTE Robot <oslab@tsinghua.edu.cn>
Signed-off-by: NZixuan Fu <r33s3n6@gmail.com>
Link: https://lore.kernel.org/r/20220514050656.2636588-1-r33s3n6@gmail.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLu Wei <luwei32@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Ziyang Xuan <william.xuanziyang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/WN42VQISGTJIXLVWCKWKBV66D42HHAER/ 
 
https://gitee.com/openeuler/kernel/issues/I7T6MN 
 
Link:https://gitee.com/openeuler/kernel/pulls/1767 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7THI2

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

The latest contribution guide is archived at
https://gitee.com/openeuler/kernel-docs and
https://gitee.com/openeuler/community/tree/master/sig/KernelSigned-off-by: NWei Li <liwei391@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Zhengchao Shao <shaozhengchao@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/Y2HCYNOFJA5N4QNNUNQKEHGLDOAVGM25/ 
 
https://gitee.com/src-openeuler/kernel/issues/I7RQ63 
 
Link:https://gitee.com/openeuler/kernel/pulls/1762 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

mainline inclusion
from mainline-v5.15-rc1
commit d812796e
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7LRJF

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

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

There was no strong reason to or not to flush barrier work items in
flush_workqueue().  And we have to make barrier work items not participate
in nr_active so we had been using WORK_NO_COLOR for them which also makes
them can't be flushed by flush_workqueue().

And the users of flush_workqueue() often do not intend to wait barrier work
items issued by flush_work().  That made the choice sound perfect.

But barrier work items have reference to internal structure (pool_workqueue)
and the worker thread[s] is/are still busy for the workqueue user when the
barrrier work items are not done.  So it is reasonable to make flush_workqueue()
also watch for flush_work() to make it more robust.

And a problem[1] reported by Li Zhe shows that we need such robustness.
The warning logs are listed below:

WARNING: CPU: 0 PID: 19336 at kernel/workqueue.c:4430 destroy_workqueue+0x11a/0x2f0
*****
destroy_workqueue: test_workqueue9 has the following busy pwq
  pwq 4: cpus=2 node=0 flags=0x0 nice=0 active=0/1 refcnt=2
      in-flight: 5658:wq_barrier_func
Showing busy workqueues and worker pools:
*****

It shows that even after drain_workqueue() returns, the barrier work item
is still in flight and the pwq (and a worker) is still busy on it.

The problem is caused by flush_workqueue() not watching flush_work():

Thread A				Worker
					/* normal work item with linked */
					process_scheduled_works()
destroy_workqueue()			  process_one_work()
  drain_workqueue()			    /* run normal work item */
				 /--	    pwq_dec_nr_in_flight()
    flush_workqueue()	    <---/
		/* the last normal work item is done */
  sanity_check				  process_one_work()
				       /--  raw_spin_unlock_irq(&pool->lock)
    raw_spin_lock_irq(&pool->lock)  <-/     /* maybe preempt */
    *WARNING*				    wq_barrier_func()
					    /* maybe preempt by cond_resched() */

Thread A can get the pool lock after the Worker unlocks the pool lock before
running wq_barrier_func().  And if there is any preemption happen around
wq_barrier_func(), destroy_workqueue()'s sanity check is more likely to
get the lock and catch it.  (Note: preemption is not necessary to cause the bug,
the unlocking is enough to possibly trigger the WARNING.)

A simple solution might be just executing all linked barrier work items
once without releasing pool lock after the head work item's
pwq_dec_nr_in_flight().  But this solution has two problems:

  1) the head work item might also be barrier work item when the user-queued
     work item is cancelled. For example:
	thread 1:		thread 2:
	queue_work(wq, &my_work)
	flush_work(&my_work)
				cancel_work_sync(&my_work);
	/* Neiter my_work nor the barrier work is scheduled. */
				destroy_workqueue(wq);
	/* This is an easier way to catch the WARNING. */

  2) there might be too much linked barrier work items and running them
     all once without releasing pool lock just causes trouble.

The only solution is to make flush_workqueue() aslo watch barrier work
items.  So we have to assign a color to these barrier work items which
is the color of the head (user-queued) work item.

Assigning a color doesn't cause any problem in ative management, because
the prvious patch made barrier work items not participate in nr_active
via WORK_STRUCT_INACTIVE rather than reliance on the (old) WORK_NO_COLOR.

[1]: https://lore.kernel.org/lkml/20210812083814.32453-1-lizhe.67@bytedance.com/Reported-by: NLi Zhe <lizhe.67@bytedance.com>
Signed-off-by: NLai Jiangshan <laijs@linux.alibaba.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NZeng Heng <zengheng4@huawei.com>

mainline inclusion
from mainline-v5.15-rc1
commit 018f3a13
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7LRJF

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

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

Currently, WORK_NO_COLOR has two meanings:
	Not participate in flushing
	Not participate in nr_active

And only non-barrier work items are marked with WORK_STRUCT_INACTIVE
when they are in inactive_works list.  The barrier work items are not
marked INACTIVE even linked in inactive_works list since these tail
items are always moved together with the head work item.

These definitions are simple, clean and practical. (Except a small
blemish that only the first meaning of WORK_NO_COLOR is documented in
include/linux/workqueue.h while both meanings are in workqueue.c)

But dual-purpose WORK_NO_COLOR used for barrier work items has proven to
be problematical[1].  Only the second purpose is obligatory.  So we plan
to make barrier work items participate in flushing but keep them still
not participating in nr_active.

So the plan is to mark barrier work items inactive without using
WORK_NO_COLOR in this patch so that we can assign a flushing color to
them in next patch.

The reasonable way is to add or reuse a bit in work data of the work
item.  But adding a bit will double the size of pool_workqueue.

Currently, WORK_STRUCT_INACTIVE is only used in try_to_grab_pending()
for user-queued work items and try_to_grab_pending() can't work for
barrier work items.  So we extend WORK_STRUCT_INACTIVE to also mark
barrier work items no matter which list they are in because we don't
need to determind which list a barrier work item is in.

So the meaning of WORK_STRUCT_INACTIVE becomes just "the work items don't
participate in nr_active" (no matter whether it is a barrier work item or
a user-queued work item).  And WORK_STRUCT_INACTIVE for user-queued work
items means they are in inactive_works list.

This patch does it by setting WORK_STRUCT_INACTIVE for barrier work items
in insert_wq_barrier() and checking WORK_STRUCT_INACTIVE first in
pwq_dec_nr_in_flight().  And the meaning of WORK_NO_COLOR is reduced to
only "not participating in flushing".

There is no functionality change intended in this patch.  Because
WORK_NO_COLOR+WORK_STRUCT_INACTIVE represents the previous WORK_NO_COLOR
in meaning and try_to_grab_pending() doesn't use for barrier work items
and avoids being confused by this extended WORK_STRUCT_INACTIVE.

A bunch of comment for nr_active & WORK_STRUCT_INACTIVE is also added for
documenting how WORK_STRUCT_INACTIVE works in nr_active management.

[1]: https://lore.kernel.org/lkml/20210812083814.32453-1-lizhe.67@bytedance.com/Signed-off-by: NLai Jiangshan <laijs@linux.alibaba.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NZeng Heng <zengheng4@huawei.com>

mainline inclusion
from mainline-v5.15-rc1
commit d21cece0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7LRJF

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

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

Add a local var @work_flags to calculate work_flags step by step, so that
we don't need to squeeze several flags in only the last line of code.

Parepare for next patch to add a bit to barrier work item's flag.  Not
squshing this to next patch makes it clear that what it will have changed.

No functional change intended.
Signed-off-by: NLai Jiangshan <laijs@linux.alibaba.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NZeng Heng <zengheng4@huawei.com>

mainline inclusion
from mainline-v5.15-rc1
commit c4560c2c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7LRJF

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

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

Make pwq_dec_nr_in_flight() use work_data rather just work_color.

Prepare for later patch to get WORK_STRUCT_INACTIVE bit from work_data
in pwq_dec_nr_in_flight().

No functional change intended.
Signed-off-by: NLai Jiangshan <laijs@linux.alibaba.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NZeng Heng <zengheng4@huawei.com>

mainline inclusion
from mainline-v5.15-rc1
commit f97a4a1a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7LRJF

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

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

There are two kinds of "delayed" work items in workqueue subsystem.

One is for timer-delayed work items which are visible to workqueue users.
The other kind is for work items delayed by active management which can
not be directly visible to workqueue users.  We mixed the word "delayed"
for both kinds and caused somewhat ambiguity.

This patch renames the later one (delayed by active management) to
"inactive", because it is used for workqueue active management and
most of its related symbols are named with "active" or "activate".

All "delayed" and "DELAYED" are carefully checked and renamed one by
one to avoid accidentally changing the name of the other kind for
timer-delayed.

No functional change intended.
Signed-off-by: NLai Jiangshan <laijs@linux.alibaba.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

conflict:
	kernel/workqueue.c
Signed-off-by: NZeng Heng <zengheng4@huawei.com>

mainline inclusion
from mainline-v6.5-rc6
commit 01f4fd27087078c90a0e22860d1dfa2cd0510791
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7T6MN
CVE: NA

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

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

BUG_ON(!vlan_info) is triggered in unregister_vlan_dev() with
following testcase:

  # ip netns add ns1
  # ip netns exec ns1 ip link add bond0 type bond mode 0
  # ip netns exec ns1 ip link add bond_slave_1 type veth peer veth2
  # ip netns exec ns1 ip link set bond_slave_1 master bond0
  # ip netns exec ns1 ip link add link bond_slave_1 name vlan10 type vlan id 10 protocol 802.1ad
  # ip netns exec ns1 ip link add link bond0 name bond0_vlan10 type vlan id 10 protocol 802.1ad
  # ip netns exec ns1 ip link set bond_slave_1 nomaster
  # ip netns del ns1

The logical analysis of the problem is as follows:

1. create ETH_P_8021AD protocol vlan10 for bond_slave_1:
register_vlan_dev()
  vlan_vid_add()
    vlan_info_alloc()
    __vlan_vid_add() // add [ETH_P_8021AD, 10] vid to bond_slave_1

2. create ETH_P_8021AD protocol bond0_vlan10 for bond0:
register_vlan_dev()
  vlan_vid_add()
    __vlan_vid_add()
      vlan_add_rx_filter_info()
          if (!vlan_hw_filter_capable(dev, proto)) // condition established because bond0 without NETIF_F_HW_VLAN_STAG_FILTER
              return 0;

          if (netif_device_present(dev))
              return dev->netdev_ops->ndo_vlan_rx_add_vid(dev, proto, vid); // will be never called
              // The slaves of bond0 will not refer to the [ETH_P_8021AD, 10] vid.

3. detach bond_slave_1 from bond0:
__bond_release_one()
  vlan_vids_del_by_dev()
    list_for_each_entry(vid_info, &vlan_info->vid_list, list)
        vlan_vid_del(dev, vid_info->proto, vid_info->vid);
        // bond_slave_1 [ETH_P_8021AD, 10] vid will be deleted.
        // bond_slave_1->vlan_info will be assigned NULL.

4. delete vlan10 during delete ns1:
default_device_exit_batch()
  dev->rtnl_link_ops->dellink() // unregister_vlan_dev() for vlan10
    vlan_info = rtnl_dereference(real_dev->vlan_info); // real_dev of vlan10 is bond_slave_1
	BUG_ON(!vlan_info); // bond_slave_1->vlan_info is NULL now, bug is triggered!!!

Add S-VLAN tag related features support to bond driver. So the bond driver
will always propagate the VLAN info to its slaves.

Fixes: 8ad227ff ("net: vlan: add 802.1ad support")
Suggested-by: NIdo Schimmel <idosch@idosch.org>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NIdo Schimmel <idosch@nvidia.com>
Link: https://lore.kernel.org/r/20230802114320.4156068-1-william.xuanziyang@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>

stable inclusion
from stable-v4.19.290
commit 11e6919ae028b5de1fc48007354ea07069561b31
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7RQ63
CVE: CVE-2023-34319

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

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

commit 534fc31d09b706a16d83533e16b5dc855caf7576 upstream.

It is possible that a guest can send a packet that contains a head + 18
slots and yet has a len <= XEN_NETBACK_TX_COPY_LEN. This causes nr_slots
to underflow in xenvif_get_requests() which then causes the subsequent
loop's termination condition to be wrong, causing a buffer overrun of
queue->tx_map_ops.

Rework the code to account for the extra frag_overflow slots.

This is CVE-2023-34319 / XSA-432.

Fixes: ad7f402a ("xen/netback: Ensure protocol headers don't fall in the non-linear area")
Signed-off-by: NRoss Lagerwall <ross.lagerwall@citrix.com>
Reviewed-by: NPaul Durrant <paul@xen.org>
Reviewed-by: NWei Liu <wei.liu@kernel.org>
Signed-off-by: NJuergen Gross <jgross@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Conflicts:
	drivers/net/xen-netback/netback.c
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>

Merge Pull Request from: @LiuYongQiang0816 
 
two patches from Dongchenchen 
 
Link:https://gitee.com/openeuler/kernel/pulls/1761 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> 

mainline inclusion
from mainline-v6.5-rc3
commit 5c9241f3ceab3257abe2923a59950db0dc8bb737
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7QXHX
CVE: CVE-2023-4194

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

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

Commit 66b2c338 initializes the "sk_uid" field in the protocol socket
(struct sock) from the "/dev/tapX" device node's owner UID. Per original
commit 86741ec2 ("net: core: Add a UID field to struct sock.",
2016-11-04), that's wrong: the idea is to cache the UID of the userspace
process that creates the socket. Commit 86741ec2 mentions socket() and
accept(); with "tap", the action that creates the socket is
open("/dev/tapX").

Therefore the device node's owner UID is irrelevant. In most cases,
"/dev/tapX" will be owned by root, so in practice, commit 66b2c338 has
no observable effect:

- before, "sk_uid" would be zero, due to undefined behavior
  (CVE-2023-1076),

- after, "sk_uid" would be zero, due to "/dev/tapX" being owned by root.

What matters is the (fs)UID of the process performing the open(), so cache
that in "sk_uid".

Cc: Eric Dumazet <edumazet@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Pietro Borrello <borrello@diag.uniroma1.it>
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org
Fixes: 66b2c338 ("tap: tap_open(): correctly initialize socket uid")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2173435Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>

mainline inclusion
from mainline-v6.5-rc3
commit 9bc3047374d5bec163e83e743709e23753376f0c
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7QXHX
CVE: CVE-2023-4194

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

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

Commit a096ccca initializes the "sk_uid" field in the protocol socket
(struct sock) from the "/dev/net/tun" device node's owner UID. Per
original commit 86741ec2 ("net: core: Add a UID field to struct
sock.", 2016-11-04), that's wrong: the idea is to cache the UID of the
userspace process that creates the socket. Commit 86741ec2 mentions
socket() and accept(); with "tun", the action that creates the socket is
open("/dev/net/tun").

Therefore the device node's owner UID is irrelevant. In most cases,
"/dev/net/tun" will be owned by root, so in practice, commit a096ccca
has no observable effect:

- before, "sk_uid" would be zero, due to undefined behavior
  (CVE-2023-1076),

- after, "sk_uid" would be zero, due to "/dev/net/tun" being owned by root.

What matters is the (fs)UID of the process performing the open(), so cache
that in "sk_uid".

Cc: Eric Dumazet <edumazet@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Pietro Borrello <borrello@diag.uniroma1.it>
Cc: netdev@vger.kernel.org
Cc: stable@vger.kernel.org
Fixes: a096ccca ("tun: tun_chr_open(): correctly initialize socket uid")
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2173435Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Liu Jian <liujian56@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/U6LBAC5GRFGPJNYEXQY4JLRBPV67R6GI/ 
fix CVE-2023-4128 in openEuler1.0

valis (3):
  net/sched: cls_u32: No longer copy tcf_result on update to avoid
    use-after-free
  net/sched: cls_route: No longer copy tcf_result on update to avoid
    use-after-free
  net/sched: cls_fw: No longer copy tcf_result on update to avoid
    use-after-free


-- 
2.34.1
 
https://gitee.com/src-openeuler/kernel/issues/I7SAP1 
 
Link:https://gitee.com/openeuler/kernel/pulls/1728 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Jialin Zhang <zhangjialin11@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/VXPVUTJU24XAU3PNMQNE65P6FVTS2FDS/ 
 
https://gitee.com/openeuler/kernel/issues/I65DOZ 
 
Link:https://gitee.com/openeuler/kernel/pulls/1673 

Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> 
Reviewed-by: Zucheng Zheng <zhengzucheng@huawei.com> 
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> 

mainline inclusion
from mainline-v6.5-rc5
commit 76e42ae831991c828cffa8c37736ebfb831ad5ec
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7SAP1
CVE: CVE-2023-4128

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

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

When fw_change() is called on an existing filter, the whole
tcf_result struct is always copied into the new instance of the filter.

This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the
success path, decreasing filter_cnt of the still referenced class
and allowing it to be deleted, leading to a use-after-free.

Fix this by no longer copying the tcf_result struct from the old filter.

Fixes: e35a8ee5 ("net: sched: fw use RCU")
Reported-by: Nvalis <sec@valis.email>
Reported-by: NBing-Jhong Billy Jheng <billy@starlabs.sg>
Signed-off-by: Nvalis <sec@valis.email>
Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: NVictor Nogueira <victor@mojatatu.com>
Reviewed-by: NPedro Tammela <pctammela@mojatatu.com>
Reviewed-by: NM A Ramdhan <ramdhan@starlabs.sg>
Link: https://lore.kernel.org/r/20230729123202.72406-3-jhs@mojatatu.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NLiu Jian <liujian56@huawei.com>

Conflicts:
	net/sched/cls_fw.c

stable inclusion
from stable-v4.19.291
commit ad8f36f96696a7f1d191da66637c415959bab6d8
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7SAP1
CVE: CVE-2023-4128

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

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

[ Upstream commit b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8 ]

When route4_change() is called on an existing filter, the whole
tcf_result struct is always copied into the new instance of the filter.

This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the
success path, decreasing filter_cnt of the still referenced class
and allowing it to be deleted, leading to a use-after-free.

Fix this by no longer copying the tcf_result struct from the old filter.

Fixes: 1109c005 ("net: sched: RCU cls_route")
Reported-by: Nvalis <sec@valis.email>
Reported-by: NBing-Jhong Billy Jheng <billy@starlabs.sg>
Signed-off-by: Nvalis <sec@valis.email>
Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: NVictor Nogueira <victor@mojatatu.com>
Reviewed-by: NPedro Tammela <pctammela@mojatatu.com>
Reviewed-by: NM A Ramdhan <ramdhan@starlabs.sg>
Link: https://lore.kernel.org/r/20230729123202.72406-4-jhs@mojatatu.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLiu Jian <liujian56@huawei.com>

stable inclusion
from stable-v4.19.291
commit 4aae24015ecd70d824a953e2dc5b0ca2c4769243
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7SAP1
CVE: CVE-2023-4128

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

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

[ Upstream commit 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81 ]

When u32_change() is called on an existing filter, the whole
tcf_result struct is always copied into the new instance of the filter.

This causes a problem when updating a filter bound to a class,
as tcf_unbind_filter() is always called on the old instance in the
success path, decreasing filter_cnt of the still referenced class
and allowing it to be deleted, leading to a use-after-free.

Fix this by no longer copying the tcf_result struct from the old filter.

Fixes: de5df632 ("net: sched: cls_u32 changes to knode must appear atomic to readers")
Reported-by: Nvalis <sec@valis.email>
Reported-by: NM A Ramdhan <ramdhan@starlabs.sg>
Signed-off-by: Nvalis <sec@valis.email>
Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: NVictor Nogueira <victor@mojatatu.com>
Reviewed-by: NPedro Tammela <pctammela@mojatatu.com>
Reviewed-by: NM A Ramdhan <ramdhan@starlabs.sg>
Link: https://lore.kernel.org/r/20230729123202.72406-2-jhs@mojatatu.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLiu Jian <liujian56@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Zhengchao Shao <shaozhengchao@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/7PFY2LM6OIUSJFT2K5UQ5LIDQ4XPI6T6/ 
 
https://gitee.com/src-openeuler/kernel/issues/I7NYWN 
 
Link:https://gitee.com/openeuler/kernel/pulls/1712 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

mainline inclusion
from mainline-v6.5-rc3
commit 00374d9b6d9f932802b55181be9831aa948e5b7c
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7NYWN
CVE: CVE-2023-3772

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

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

Normally, x->replay_esn and x->preplay_esn should be allocated at
xfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence the
xfrm_update_ae_params(...) is okay to update them. However, the current
implementation of xfrm_new_ae(...) allows a malicious user to directly
dereference a NULL pointer and crash the kernel like below.

BUG: kernel NULL pointer dereference, address: 0000000000000000
PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0
Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774d #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4
RIP: 0010:memcpy_orig+0xad/0x140
Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c
RSP: 0018:ffff888008f57658 EFLAGS: 00000202
RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571
RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818
R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000
FS:  00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 ? __die+0x1f/0x70
 ? page_fault_oops+0x1e8/0x500
 ? __pfx_is_prefetch.constprop.0+0x10/0x10
 ? __pfx_page_fault_oops+0x10/0x10
 ? _raw_spin_unlock_irqrestore+0x11/0x40
 ? fixup_exception+0x36/0x460
 ? _raw_spin_unlock_irqrestore+0x11/0x40
 ? exc_page_fault+0x5e/0xc0
 ? asm_exc_page_fault+0x26/0x30
 ? xfrm_update_ae_params+0xd1/0x260
 ? memcpy_orig+0xad/0x140
 ? __pfx__raw_spin_lock_bh+0x10/0x10
 xfrm_update_ae_params+0xe7/0x260
 xfrm_new_ae+0x298/0x4e0
 ? __pfx_xfrm_new_ae+0x10/0x10
 ? __pfx_xfrm_new_ae+0x10/0x10
 xfrm_user_rcv_msg+0x25a/0x410
 ? __pfx_xfrm_user_rcv_msg+0x10/0x10
 ? __alloc_skb+0xcf/0x210
 ? stack_trace_save+0x90/0xd0
 ? filter_irq_stacks+0x1c/0x70
 ? __stack_depot_save+0x39/0x4e0
 ? __kasan_slab_free+0x10a/0x190
 ? kmem_cache_free+0x9c/0x340
 ? netlink_recvmsg+0x23c/0x660
 ? sock_recvmsg+0xeb/0xf0
 ? __sys_recvfrom+0x13c/0x1f0
 ? __x64_sys_recvfrom+0x71/0x90
 ? do_syscall_64+0x3f/0x90
 ? entry_SYSCALL_64_after_hwframe+0x72/0xdc
 ? copyout+0x3e/0x50
 netlink_rcv_skb+0xd6/0x210
 ? __pfx_xfrm_user_rcv_msg+0x10/0x10
 ? __pfx_netlink_rcv_skb+0x10/0x10
 ? __pfx_sock_has_perm+0x10/0x10
 ? mutex_lock+0x8d/0xe0
 ? __pfx_mutex_lock+0x10/0x10
 xfrm_netlink_rcv+0x44/0x50
 netlink_unicast+0x36f/0x4c0
 ? __pfx_netlink_unicast+0x10/0x10
 ? netlink_recvmsg+0x500/0x660
 netlink_sendmsg+0x3b7/0x700

This Null-ptr-deref bug is assigned CVE-2023-3772. And this commit
adds additional NULL check in xfrm_update_ae_params to fix the NPD.

Fixes: d8647b79 ("xfrm: Add user interface for esn and big anti-replay windows")
Signed-off-by: NLin Ma <linma@zju.edu.cn>
Reviewed-by: NLeon Romanovsky <leonro@nvidia.com>
Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>

Conflicts:
	net/xfrm/xfrm_user.c
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>

Merge Pull Request from: @LiuYongQiang0816 
 
6 patches from lilingfeng and linan 
 
Link:https://gitee.com/openeuler/kernel/pulls/1699 

Reviewed-by: Zhang Changzhong <zhangchangzhong@huawei.com> 
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Wang ShaoBo <bobo.shaobowang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/TIRKDP6JTZEGYSBHRBDGT6TYJH7VZS2Q/ 
 
https://gitee.com/openeuler/kernel/issues/I7RC8S 
 
Link:https://gitee.com/openeuler/kernel/pulls/1697 

Reviewed-by: Wei Li <liwei391@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

mainline inclusion
from mainline-v6.0-rc3
commit 5e8daf90
category: bugfix
bugzilla: 188015, https://gitee.com/openeuler/kernel/issues/I6OERX
CVE: NA

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

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

A race condition still exists when removing and re-creating md devices
in test cases. However, it is only seen on some setups.

The race condition was tracked down to a reference still being held
to the kobject by the rdev in the md_rdev_misc_wq which will be released
in rdev_delayed_delete().

md_alloc() waits for previous deletions by waiting on the md_misc_wq,
but the md_rdev_misc_wq may still be holding a reference to a recently
removed device.

To fix this, also flush the md_rdev_misc_wq in md_alloc().
Signed-off-by: NDavid Sloan <david.sloan@eideticom.com>
[logang@deltatee.com: rewrote commit message]
Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
Signed-off-by: NSong Liu <song@kernel.org>

Conflict:
	drivers/md/md.c
Signed-off-by: NLi Nan <linan122@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

mainline inclusion
from mainline-v6.4-rc8
commit 2760904d
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7FI5Z
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.4-rc7&id=2760904d895279f87196f0fa9ec570c79fe6a2e4

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

As described in commit 38d11da5 ("dm: don't lock fs when the map is
NULL in process of resume"), a deadlock may be triggered between
do_resume() and do_mount().

This commit preserves the fix from commit 38d11da5 but moves it to
where it also serves to fix a similar deadlock between do_suspend()
and do_mount().  It does so, if the active map is NULL, by clearing
DM_SUSPEND_LOCKFS_FLAG in dm_suspend() which is called by both
do_suspend() and do_resume().

Fixes: 38d11da5 ("dm: don't lock fs when the map is NULL in process of resume")
Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com>
Signed-off-by: NMike Snitzer <snitzer@kernel.org>

Conflicts:
  drivers/md/dm-ioctl.c
Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com>
Reviewed-by: NYu Kuai <yukuai3@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>