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> 

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.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> 

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>

mainline inclusion
from mainline-v6.4-rc1
commit 38d11da5
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&id=38d11da522aacaa05898c734a1cec86f1e611129

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

Commit fa247089 ("dm: requeue IO if mapping table not yet available")
added a detection of whether the mapping table is available in the IO
submission process. If the mapping table is unavailable, it returns
BLK_STS_RESOURCE and requeues the IO.
This can lead to the following deadlock problem:

dm create                                      mount
ioctl(DM_DEV_CREATE_CMD)
ioctl(DM_TABLE_LOAD_CMD)
                               do_mount
                                vfs_get_tree
                                 ext4_get_tree
                                  get_tree_bdev
                                   sget_fc
                                    alloc_super
                                     // got &s->s_umount
                                     down_write_nested(&s->s_umount, ...);
                                   ext4_fill_super
                                    ext4_load_super
                                     ext4_read_bh
                                      submit_bio
                                      // submit and wait io end
ioctl(DM_DEV_SUSPEND_CMD)
dev_suspend
 do_resume
  dm_suspend
   __dm_suspend
    lock_fs
     freeze_bdev
      get_active_super
       grab_super
        // wait for &s->s_umount
        down_write(&s->s_umount);
  dm_swap_table
   __bind
    // set md->map(can't get here)

IO will be continuously requeued while holding the lock since mapping
table is NULL. At the same time, mapping table won't be set since the
lock is not available.
Like request-based DM, bio-based DM also has the same problem.

It's not proper to just abort IO if the mapping table not available.
So clear DM_SKIP_LOCKFS_FLAG when the mapping table is NULL, this
allows the DM table to be loaded and the IO submitted upon resume.

Fixes: fa247089 ("dm: requeue IO if mapping table not yet available")
Cc: stable@vger.kernel.org
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>

mainline inclusion
from mainline-v5.18-rc1
commit fa247089
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7FI78
CVE: NA

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

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

Update both bio-based and request-based DM to requeue IO if the
mapping table not available.

This race of IO being submitted before the DM device ready is so
narrow, yet possible for initial table load given that the DM device's
request_queue is created prior, that it best to requeue IO to handle
this unlikely case.
Reported-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NMike Snitzer <snitzer@redhat.com>
Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com>
Reviewed-by: NYu Kuai <yukuai3@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

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

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

This reverts commit 90d1a836.

It's not proper to just abort IO when the map is not ready.
So revert this and requeue IO to keep consistent with the community.
Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com>
Reviewed-by: NYu Kuai <yukuai3@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

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

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

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

Must check pmd->fail_io before using pmd->data_sm since
pmd->data_sm may be destroyed by other processes.

       P1(kworker)                             P2(message)
do_worker
 process_prepared
  process_prepared_discard_passdown_pt2
   dm_pool_dec_data_range
                                    pool_message
                                     commit
                                      dm_pool_commit_metadata
                                        ↓
                                       // commit failed
                                      metadata_operation_failed
                                       abort_transaction
                                        dm_pool_abort_metadata
                                         __open_or_format_metadata
                                           ↓
                                          dm_sm_disk_open
                                            ↓
                                           // open failed
                                           // pmd->data_sm is NULL
    dm_sm_dec_blocks
      ↓
     // try to access pmd->data_sm --> UAF

As shown above, if dm_pool_commit_metadata() and
dm_pool_abort_metadata() fail in pool_message process, kworker may
trigger UAF.

Fixes: be500ed7 ("dm space maps: improve performance with inc/dec on ranges of blocks")
Cc: stable@vger.kernel.org
Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com>
Signed-off-by: NMike Snitzer <snitzer@kernel.org>

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

Merge Pull Request from: @ci-robot 
 
PR sync from: Ruan Jinjie <ruanjinjie@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/RUVYH7GZGYAK3FORCDR2XWXWJUTLLM2M/ 
Backport CVE-2023-4132 fix commits.

Duoming Zhou (2):
  media: usb: siano: Fix use after free bugs caused by do_submit_urb
  media: usb: siano: Fix warning due to null work_func_t function
    pointer


-- 
2.34.1
 
https://gitee.com/src-openeuler/kernel/issues/I7QE3A 
 
Link:https://gitee.com/openeuler/kernel/pulls/1662 

Reviewed-by: Liu YongQiang <liuyongqiang13@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@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/ZNHCPUGKPZ3MVQUTQ3JGCFC6ISX3P3I5/ 
 
https://gitee.com/openeuler/kernel/issues/I7PN0A 
 
Link:https://gitee.com/openeuler/kernel/pulls/1696 

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

stable inclusion
from stable-v4.19.289
commit cfef7bbf0dca27209ea5d82d7060d4fc2c0d72ea
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7RC8S
CVE: NA

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

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

Upstream commit: 522b1d69219d8f083173819fde04f994aa051a98

Add a fix for the Zen2 VZEROUPPER data corruption bug where under
certain circumstances executing VZEROUPPER can cause register
corruption or leak data.

The optimal fix is through microcode but in the case the proper
microcode revision has not been applied, enable a fallback fix using
a chicken bit.
Signed-off-by: NBorislav Petkov (AMD) <bp@alien8.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Conflicts:
    arch/x86/include/asm/microcode_amd.h
    arch/x86/include/asm/msr-index.h
    arch/x86/kernel/cpu/amd.c
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

Merge Pull Request from: @LiuYongQiang0816 
 
4 patches from cgroup ,net and x86 subsystem 
 
Link:https://gitee.com/openeuler/kernel/pulls/1694 

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

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

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

BUG 'sleeping function called from invalid context' reported when
setup MPAM driver, it was blamed to 0f4acaeb ("arm64/mpam:
Fix mpam corrupt when cpu online"), which reported a 'Bad PC' BUG,
but missing the right conclusion, finally disabling irqs before calling
cpuhp_setup_state() may only affect the probability of reproduction.

The reason why triggerring 'Bad PC' BUG report is because mpam_enable()
is __init type function, and may schedule out after calling
__cpuhp_setup_state()->__might_sleep(), so the space of mpam_enable()
might be freed after scheduling back.

As we have changed mpam_enable() to non-init type function, we can
revert commit 0f4acaeb directly, to solve these both two problems.

Fixes: 0f4acaeb ("arm64/mpam: Fix mpam corrupt when cpu online")
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>

stable inclusion
from stable-v4.19.288
commit 6f639f6ad1796d291f5e0ea4bd5a47968c9c1f81
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7RC8S
CVE: NA

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

[ Upstream commit 85d38d58 ]

When booting with "intremap=off" and "x2apic_phys" on the kernel command
line, the physical x2APIC driver ends up being used even when x2APIC
mode is disabled ("intremap=off" disables x2APIC mode). This happens
because the first compound condition check in x2apic_phys_probe() is
false due to x2apic_mode == 0 and so the following one returns true
after default_acpi_madt_oem_check() having already selected the physical
x2APIC driver.

This results in the following panic:

   kernel BUG at arch/x86/kernel/apic/io_apic.c:2409!
   invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
   CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0-rc2-ver4.1rc2 #2
   Hardware name: Dell Inc. PowerEdge R6515/07PXPY, BIOS 2.3.6 07/06/2021
   RIP: 0010:setup_IO_APIC+0x9c/0xaf0
   Call Trace:
    <TASK>
    ? native_read_msr
    apic_intr_mode_init
    x86_late_time_init
    start_kernel
    x86_64_start_reservations
    x86_64_start_kernel
    secondary_startup_64_no_verify
    </TASK>

which is:

setup_IO_APIC:
  apic_printk(APIC_VERBOSE, "ENABLING IO-APIC IRQs\n");
  for_each_ioapic(ioapic)
  	BUG_ON(mp_irqdomain_create(ioapic));

Return 0 to denote that x2APIC has not been enabled when probing the
physical x2APIC driver.

  [ bp: Massage commit message heavily. ]

Fixes: 9ebd680b ("x86, apic: Use probe routines to simplify apic selection")
Signed-off-by: NDheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
Signed-off-by: NBorislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: NKishon Vijay Abraham I <kvijayab@amd.com>
Reviewed-by: NVasant Hegde <vasant.hegde@amd.com>
Reviewed-by: NCyrill Gorcunov <gorcunov@gmail.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20230616212236.1389-1-dheerajkumar.srivastava@amd.comSigned-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>