Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Oct 27, 2022
  3. Oct 25, 2022
    • Jialiang Wang's avatar
      nfp: fix use-after-free in area_cache_get() · 187e173a
      Jialiang Wang authored 
      mainline inclusion
from mainline-v6.0-rc1
commit 02e1a114fdb71e59ee6770294166c30d437bf86a
category: bugfix
bugzilla: 187867, https://gitee.com/src-openeuler/kernel/issues/I5W7B5
CVE: CVE-2022-3545

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

area_cache_get() is used to distribute cache->area and set cache->id,
 and if cache->id is not 0 and cache->area->kref refcount is 0, it will
 release the cache->area by nfp_cpp_area_release(). area_cache_get()
 set cache->id before cpp->op->area_init() and nfp_cpp_area_acquire().

But if area_init() or nfp_cpp_area_acquire() fails, the cache->id is
 is already set but the refcount is not increased as expected. At this
 time, calling the nfp_cpp_area_release() will cause use-after-free.

To avoid the use-after-free, set cache->id after area_init() and
 nfp_cpp_area_acquire() complete successfully.

Note: This vulnerability is triggerable by providing emulated device
 equipped with specified configuration.

 BUG: KASAN: use-after-free ...
      4.19.90-2210.4.0
      187e173a
    • Duoming Zhou's avatar
      mISDN: fix use-after-free bugs in l1oip timer handlers · 20fb5faf
      Duoming Zhou authored 
      mainline inclusion
from mainline-v6.1-rc1
commit 2568a7e0832ee30b0a351016d03062ab4e0e0a3f
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7YH


CVE: CVE-2022-3565

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

The l1oip_cleanup() traverses the l1oip_ilist and calls
release_card() to cleanup module and stack. However,
release_card() calls del_timer() to delete the timers
such as keep_tl and timeout_tl. If the timer handler is
running, the del_timer() will not stop it and result in
UAF bugs. One of the processes is shown below:

    (cleanup routine)          |        (timer handler)
release_card()                 | l1oip_timeout()
 ...                           |
 del_timer()                   | ...
 ...                           |
 kfree(hc) //FREE              |
                               | hc->timeout_on = 0 //USE

Fix by calling del_timer_sync() in release_card(), which
makes sure the timer handlers have finished before the
resources, such as l1oip and so on, have been deallocated.

What's more, the hc->workq and hc->socket_thread can kick
those timers right back in. We add a bool flag to show
if card is released. Then, check this flag in hc->workq
and hc->socket_thread.

Fixes: 3712b42d ("Add layer1 over IP support")
Signed-off-by: default avatarDuoming Zhou <duoming@zju.edu.cn>
Reviewed-by: default avatarLeon Romanovsky <leonro@nvidia.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarGUO Zihua <guozihua@huawei.com>
Reviewed-by: default avatarGONG Ruiqi <gongruiqi1@huawei.com>
Reviewed-by: default avatarWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      20fb5faf
    • Kuniyuki Iwashima's avatar
      tcp: Fix data races around icsk->icsk_af_ops. · 1ae8a44b
      Kuniyuki Iwashima authored 
      mainline inclusion
from mainline-v6.1-rc1
commit f49cd2f4d6170d27a2c61f1fecb03d8a70c91f57
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7ZF


CVE: CVE-2022-3566

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

setsockopt(IPV6_ADDRFORM) and tcp_v6_connect() change icsk->icsk_af_ops
under lock_sock(), but tcp_(get|set)sockopt() read it locklessly.  To
avoid load/store tearing, we need to add READ_ONCE() and WRITE_ONCE()
for the reads and writes.

Thanks to Eric Dumazet for providing the syzbot report:

BUG: KCSAN: data-race in tcp_setsockopt / tcp_v6_connect

write to 0xffff88813c624518 of 8 bytes by task 23936 on cpu 0:
tcp_v6_connect+0x5b3/0xce0 net/ipv6/tcp_ipv6.c:240
__inet_stream_connect+0x159/0x6d0 net/ipv4/af_inet.c:660
inet_stream_connect+0x44/0x70 net/ipv4/af_inet.c:724
__sys_connect_file net/socket.c:1976 [inline]
__sys_connect+0x197/0x1b0 net/socket.c:1993
__do_sys_connect net/socket.c:2003 [inline]
__se_sys_connect net/socket.c:2000 [inline]
__x64_sys_connect+0x3d/0x50 net/socket.c:2000
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

read to 0xffff88813c624518 of 8 bytes by task 23937 on cpu 1:
tcp_setsockopt+0x147/0x1c80 net/ipv4/tcp.c:3789
sock_common_setsockopt+0x5d/0x70 net/core/sock.c:3585
__sys_setsockopt+0x212/0x2b0 net/socket.c:2252
__do_sys_setsockopt net/socket.c:2263 [inline]
__se_sys_setsockopt net/socket.c:2260 [inline]
__x64_sys_setsockopt+0x62/0x70 net/socket.c:2260
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd

value changed: 0xffffffff8539af68 -> 0xffffffff8539aff8

Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 23937 Comm: syz-executor.5 Not tainted
6.0.0-rc4-syzkaller-00331-g4ed9c1e971b1-dirty #0

Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 08/26/2022

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
Reported-by: default avatarEric Dumazet <edumazet@google.com>
Signed-off-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
Conflicts:
	net/ipv4/tcp.c
	net/ipv6/ipv6_sockglue.c
	net/ipv6/tcp_ipv6.c
Signed-off-by: default avatarZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: default avatarYue Haibing <yuehaibing@huawei.com>
Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      1ae8a44b
    • Maxim Mikityanskiy's avatar
      Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu · 1c1e7cf5
      Maxim Mikityanskiy authored 
      mainline inclusion
from bluetooth-next
commit 89f9f3cb86b1c63badaf392a83dd661d56cc50b1
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7XW
CVE: CVE-2022-3564

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

Fix the race condition between the following two flows that run in
parallel:

1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
   __sock_queue_rcv_skb.

2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.

An SKB can be queued by the first flow and immediately dequeued and
freed by the second flow, therefore the callers of l2cap_reassemble_sdu
can't use the SKB after that function returns. However, some places
continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
short time after l2cap_reassemble_sdu returns, leading to a
use-after-free condition (the stack trace is below, line numbers for
kernel 5.19.8).

Fix it by keeping a local copy of struct l2cap_ctrl.

BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169

Workqueue: hci0 hci_rx_work [bluetooth]
Call Trace:
 <TASK>
 dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
 print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429)
 ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
 kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493)
 ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
 l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
 l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth
 ret_from_fork (arch/x86/entry/entry_64.S:306)
 </TASK>

Allocated by task 43169:
 kasan_save_stack (mm/kasan/common.c:39)
 __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
 kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293)
 __alloc_skb (net/core/skbuff.c:414)
 l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth
 l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth
 hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth
 process_one_work (kernel/workqueue.c:2289)
 worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437)
 kthread (kernel/kthread.c:376)
 ret_from_fork (arch/x86/entry/entry_64.S:306)

Freed by task 27920:
 kasan_save_stack (mm/kasan/common.c:39)
 kasan_set_track (mm/kasan/common.c:45)
 kasan_set_free_info (mm/kasan/generic.c:372)
 ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328)
 slab_free_freelist_hook (mm/slub.c:1780)
 kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553)
 skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323)
 bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth
 l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth
 sock_read_iter (net/socket.c:1087)
 new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401)
 vfs_read (fs/read_write.c:482)
 ksys_read (fs/read_write.c:620)
 do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)

Link: https://lore.kernel.org/linux-bluetooth/CAKErNvoqga1WcmoR3-0875esY6TVWFQDandbVZncSiuGPBQXLA@mail.gmail.com/T/#u


Fixes: d2a7ac5d ("Bluetooth: Add the ERTM receive state machine")
Fixes: 4b51dae9 ("Bluetooth: Add streaming mode receive and incoming packet classifier")
Signed-off-by: default avatarMaxim Mikityanskiy <maxtram95@gmail.com>
Signed-off-by: default avatarLuiz Augusto von Dentz <luiz.von.dentz@intel.com>

conflicts：
	net/bluetooth/l2cap_core.c

Signed-off-by: default avatarXia Longlong <xialonglong1@huawei.com>
Reviewed-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      1c1e7cf5
    • openeuler-ci-bot's avatar
      !134 scsi: megaraid_sas: Add support for MegaRAID Aero controllers · f0db3aa1
      openeuler-ci-bot authored 
      Merge Pull Request from: @babyihc 
 
This PR is cherry-pick from upstream "scsi: megaraid_sas: Add support for MegaRAID Aero controllers"

Upstream patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=469f72ddc618d0afe05176b18ae6ebefb1fc6fe2 
 
Link:https://gitee.com/openeuler/kernel/pulls/134

 
Reviewed-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
Signed-off-by: default avatarXie XiuQi <xiexiuqi@huawei.com>
      f0db3aa1
    • openeuler-ci-bot's avatar
      !138 vfio-pci: Mask cap zero · 4a152517
      openeuler-ci-bot authored 
      Merge Pull Request from: @babyihc 
 
This PR is cherry-pick from upstream "vfio-pci: Mask cap zero"

Upstream patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bc138db1b96264b9c1779cf18d5a3b186aa90066
 
 
Link:https://gitee.com/openeuler/kernel/pulls/138

 
Reviewed-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
Signed-off-by: default avatarXie XiuQi <xiexiuqi@huawei.com>
      4a152517
  5. Oct 24, 2022
  7. Oct 21, 2022
  9. Oct 20, 2022
  11. Oct 19, 2022
  13. Oct 18, 2022
  15. Oct 17, 2022
    • Qian Cai's avatar
      mm/hotplug: silence a lockdep splat with printk() · 988dd3e9
      Qian Cai authored 
      mainline inclusion
from mainline-v5.6-rc1
commit 4a55c0474a92d5c418bcbbe122368de0910aeac2q
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5T5DD
CVE: NA

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

It is not that hard to trigger lockdep splats by calling printk from
under zone->lock.  Most of them are false positives caused by lock
chains introduced early in the boot process and they do not cause any
real problems (although most of the early boot lock dependencies could
happen after boot as well).  There are some console drivers which do
allocate from the printk context as well and those should be fixed.  In
any case, false positives are not that trivial to workaround and it is
far from optimal to lose lockdep functionality for something that is a
non-issue.

So change has_unmovable_pages() so that it no longer calls dump_page()
itself - instead it returns a "struct page *" of the unmovable page back
to the caller so that in the case of a has_u...
      988dd3e9
    • Xia Fukun's avatar
      init/Kconfig: Add SMP to the dependencies of QOS_SCHED · 72b3422d
      Xia Fukun authored 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5UPB0
CVE: NA

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

After CONFIG_SMP is disabled during kernel compilation,
CONFIG_QOS_SCHED is not disabled.
As a result, the following error occurs:

kernel/sched/fair.c: In function ‘check_qos_cfs_rq’:
kernel/sched/fair.c:7324:4: error: implicit declaration of function
‘sched_idle_cpu’; did you mean ‘sched_idle_rq’?
[-Werror=implicit-function-declaration]
 7324 |   !sched_idle_cpu(smp_processor_id()) &&
      |    ^~~~~~~~~~~~~~
./include/linux/compiler.h:78:42: note: in definition of macro ‘unlikely’
   78 | # define unlikely(x) __builtin_expect(!!(x), 0)
      |                                          ^
  CC      mm/highmem.o
kernel/sched/fair.c: In function ‘pick_next_task_fair’:
kernel/sched/fair.c:7599:43: error: ‘struct rq’ has no member named ‘online’
 7599 |   if (cfs_rq->...
      72b3422d
  17. Oct 14, 2022
    • Ma Wupeng's avatar
      mm/rmap: Fix kabi broken in anon_vma · 6d5d324d
      Ma Wupeng authored 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5USOP


CVE: CVE-2022-42703

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

In order to fix CVE-2022-42703, degree in struct anon_vma is splited into
two variables(num_children, num_active_vmas) and this will lead to broken
kabi.

Since struct anon_vma is only used by mm module and referenced by other
struct as pointers. So we can ignore this kabi change warning.

For variable degree in struct anon_vma, previous patch has already
delete this but this will lead to kabi change. Add it back at the same
position. For variables(num_children, num_active_vmas), put them
between macro __GENKSYMS__.

Signed-off-by: default avatarMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      6d5d324d
    • Jann Horn's avatar
      mm/rmap: Fix anon_vma->degree ambiguity leading to double-reuse · a3544c89
      Jann Horn authored 
      stable inclusion
from stable-v4.19.257
commit 6dbfc25d68d922736381988d64156a649ccf7bf1
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5USOP


CVE: CVE-2022-42703

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

commit 2555283eb40df89945557273121e9393ef9b542b upstream.

anon_vma->degree tracks the combined number of child anon_vmas and VMAs
that use the anon_vma as their ->anon_vma.

anon_vma_clone() then assumes that for any anon_vma attached to
src->anon_vma_chain other than src->anon_vma, it is impossible for it to
be a leaf node of the VMA tree, meaning that for such VMAs ->degree is
elevated by 1 because of a child anon_vma, meaning that if ->degree
equals 1 there are no VMAs that use the anon_vma as their ->anon_vma.

This assumption is wrong because the ->degree optimization leads to leaf
nodes being abandoned on anon_vma_clone() - an existing anon_vma is
reused and no new parent-child relationship is created.  So it is
possible to reuse an anon_vma for one VMA while it is still tied to
another VMA.

This is an issue because is_mergeable_anon_vma() and its callers assume
that if two VMAs have the same ->anon_vma, the list of anon_vmas
attached to the VMAs is guaranteed to be the same.  When this assumption
is violated, vma_merge() can merge pages into a VMA that is not attached
to the corresponding anon_vma, leading to dangling page->mapping
pointers that will be dereferenced during rmap walks.

Fix it by separately tracking the number of child anon_vmas and the
number of VMAs using the anon_vma as their ->anon_vma.

Fixes: 7a3ef208 ("mm: prevent endless growth of anon_vma hierarchy")
Cc: stable@kernel.org
Acked-by: default avatarMichal Hocko <mhocko@suse.com>
Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
Signed-off-by: default avatarJann Horn <jannh@google.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: default avatarMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: default avatarKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      a3544c89
    • Hyunwoo Kim's avatar
      HID: roccat: Fix use-after-free in roccat_read() · 4d870684
      Hyunwoo Kim authored 
      mainline inclusion
from mainline master
commit cacdb14b1c8d3804a3a7d31773bc7569837b71a4
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5U1PE


CVE: CVE-2022-41850

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

roccat_report_event() is responsible for registering
roccat-related reports in struct roccat_device.

int roccat_report_event(int minor, u8 const *data)
{
	struct roccat_device *device;
	struct roccat_reader *reader;
	struct roccat_report *report;
	uint8_t *new_value;

	device = devices[minor];

	new_value = kmemdup(data, device->report_size, GFP_ATOMIC);
	if (!new_value)
		return -ENOMEM;

	report = &device->cbuf[device->cbuf_end];

	/* passing NULL is safe */
	kfree(report->value);
	...

The registered report is stored in the struct roccat_device member
"struct roccat_report cbuf[ROCCAT_CBUF_SIZE];".
If more reports are received than the "ROCCAT_CBUF_SIZE" value,
kfree() the saved report from cbuf[0] and allocates a new reprot.
Since there is no lock when this kfree() is performed,
kfree() can be performed even while reading the saved report.

static ssize_t roccat_read(struct file *file, char __user *buffer,
		size_t count, loff_t *ppos)
{
	struct roccat_reader *reader = file->private_data;
	struct roccat_device *device = reader->device;
	struct roccat_report *report;
	ssize_t retval = 0, len;
	DECLARE_WAITQUEUE(wait, current);

	mutex_lock(&device->cbuf_lock);

	...

	report = &device->cbuf[reader->cbuf_start];
	/*
	 * If report is larger than requested amount of data, rest of report
	 * is lost!
	 */
	len = device->report_size > count ? count : device->report_size;

	if (copy_to_user(buffer, report->value, len)) {
		retval = -EFAULT;
		goto exit_unlock;
	}
	...

The roccat_read() function receives the device->cbuf report and
delivers it to the user through copy_to_user().
If the N+ROCCAT_CBUF_SIZE th report is received while copying of
the Nth report->value is in progress, the pointer that copy_to_user()
is working on is kfree()ed and UAF read may occur. (race condition)

Since the device node of this driver does not set separate permissions,
this is not a security vulnerability, but because it is used for
requesting screen display of profile or dpi settings,
a user using the roccat device can apply udev to this device node or
There is a possibility to use it by giving.

Signed-off-by: default avatarHyunwoo Kim <imv4bel@gmail.com>
Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
Signed-off-by: default avatarCai Xinchen <caixinchen1@huawei.com>
Reviewed-by: default avatarRuiqi Gong <gongruiqi1@huawei.com>
Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
      4d870684
  19. Oct 12, 2022
  21. Oct 11, 2022