deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2021-47002
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

SUNRPC: Fix null pointer dereference in svc_rqst_free()

When alloc_pages_node() returns null in svc_rqst_alloc(), the
null rq_scratch_page pointer will be dereferenced when calling
put_page() in svc_rqst_free(). Fix it by adding a null check.

Addresses-Coverity: ("Dereference after null check")
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1e10f58f1c9a6b667b045513c7a4e6111c24fe7c; https://git.kernel.org/stable/c/3de81c1e84bf84803308da3272a829a7655c5336; https://git.kernel.org/stable/c/b9f83ffaa0c096b4c832a43964fe6bff3acffe10
CVE: CVE-2021-47003
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: idxd: Fix potential null dereference on pointer status

There are calls to idxd_cmd_exec that pass a null status pointer however
a recent commit has added an assignment to *status that can end up
with a null pointer dereference.  The function expects a null status
pointer sometimes as there is a later assignment to *status where
status is first null checked.  Fix the issue by null checking status
before making the assignment.

Addresses-Coverity: ("Explicit null dereferenced")
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2280b4cc29d8cdd2be3d1b2d1ea4f958e2131c97; https://git.kernel.org/stable/c/28ac8e03c43dfc6a703aa420d18222540b801120; https://git.kernel.org/stable/c/5756f757c72501ef1a16f5f63f[PII_REDACTED]80e9
CVE: CVE-2021-47004
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to avoid touching checkpointed data in get_victim()

In CP disabling mode, there are two issues when using LFS or SSR | AT_SSR
mode to select victim:

1. LFS is set to find source section during GC, the victim should have
no checkpointed data, since after GC, section could not be set free for
reuse.

Previously, we only check valid chpt blocks in current segment rather
than section, fix it.

2. SSR | AT_SSR are set to find target segment for writes which can be
fully filled by checkpointed and newly written blocks, we should never
select such segment, otherwise it can cause panic or data corruption
during allocation, potential case is described as below:

 a) target segment has 'n' (n < 512) ckpt valid blocks
 b) GC migrates 'n' valid blocks to other segment (segment is still
    in dirty list)
 c) GC migrates '512 - n' blocks to target segment (segment has 'n'
    cp_vblocks and '512 - n' vblocks)
 d) If GC selects target segment via {AT,}SSR allocator, however there
    is no free space in targe segment.
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/105155a8146ddb54c119d8318964eef3859d109d; https://git.kernel.org/stable/c/1e116f87825f01a[PII_REDACTED]196882746b16f63; https://git.kernel.org/stable/c/211372b2571520e394b56b431a[PII_REDACTED]b3ff
CVE: CVE-2021-47005
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: endpoint: Fix NULL pointer dereference for ->get_features()

get_features ops of pci_epc_ops may return NULL, causing NULL pointer
dereference in pci_epf_test_alloc_space function. Let us add a check for
pci_epc_feature pointer in pci_epf_test_bind before we access it to avoid
any such NULL pointer dereference and return -ENOTSUPP in case
pci_epc_feature is not found.

When the patch is not applied and EPC features is not implemented in the
platform driver, we see the following dump due to kernel NULL pointer
dereference.

Call trace:
 pci_epf_test_bind+0xf4/0x388
 pci_epf_bind+0x3c/0x80
 pci_epc_epf_link+0xa8/0xcc
 configfs_symlink+0x1a4/0x48c
 vfs_symlink+0x104/0x184
 do_symlinkat+0x80/0xd4
 __arm64_sys_symlinkat+0x1c/0x24
 el0_svc_common.constprop.3+0xb8/0x170
 el0_svc_handler+0x70/0x88
 el0_svc+0x8/0x640
Code: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400)
---[ end trace a438e3c5a24f9df0 ]---
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0169d4f0bee44fdfef908c13ed21fcb326c38695; https://git.kernel.org/stable/c/6613bc2301ba291a1c5a90e1dc24cf3edf223c03; https://git.kernel.org/stable/c/679ebad058b8168f10e63876d63b0877fd2fe784
CVE: CVE-2021-47006
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

ARM: 9064/1: hw_breakpoint: Do not directly check the event's overflow_handler hook

The commit 1879445dfa7b ("perf/core: Set event's default
::overflow_handler()") set a default event->overflow_handler in
perf_event_alloc(), and replace the check event->overflow_handler with
is_default_overflow_handler(), but one is missing.

Currently, the bp->overflow_handler can not be NULL. As a result,
enable_single_step() is always not invoked.

Comments from Zhen Lei:

 https://patchwork.kernel.org/project/linux-arm-kernel/patch/[PII_REDACTED]5934.2001-1-thunder.leizhen@huawei.com/
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3ed8832aeaa9a37b0fc386bb72ff604352567c80; https://git.kernel.org/stable/c/555a70f7fff03bd[PII_REDACTED]05c47ae27dbdaac; https://git.kernel.org/stable/c/[PII_REDACTED]08bf6b8934eec0dfdb3e46dcb917de
CVE: CVE-2021-47007
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix panic during f2fs_resize_fs()

f2fs_resize_fs() hangs in below callstack with testcase:
- mkfs 16GB image & mount image
- dd 8GB fileA
- dd 8GB fileB
- sync
- rm fileA
- sync
- resize filesystem to 8GB

kernel BUG at segment.c:2484!
Call Trace:
 allocate_segment_by_default+0x92/0xf0 [f2fs]
 f2fs_allocate_data_block+0x44b/0x7e0 [f2fs]
 do_write_page+0x5a/0x110 [f2fs]
 f2fs_outplace_write_data+0x55/0x100 [f2fs]
 f2fs_do_write_data_page+0x392/0x850 [f2fs]
 move_data_page+0x233/0x320 [f2fs]
 do_garbage_collect+0x14d9/0x1660 [f2fs]
 free_segment_range+0x1f7/0x310 [f2fs]
 f2fs_resize_fs+0x118/0x330 [f2fs]
 __f2fs_ioctl+0x487/0x3680 [f2fs]
 __x64_sys_ioctl+0x8e/0xd0
 do_syscall_64+0x33/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

The root cause is we forgot to check that whether we have enough space
in resized filesystem to store all valid blocks in before-resizing
filesystem, then allocator will run out-of-space during block migration
in free_segment_range().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-754
References: https://git.kernel.org/stable/c/1c20a4896409f5ca1c770e1880c33d0a28a8b10f; https://git.kernel.org/stable/c/3ab0598e6d860ef49d029943ba80f627c15c15d6; https://git.kernel.org/stable/c/822054e5026c43b1dd60cf387dd999e95ee2ecc2
CVE: CVE-2021-47008
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: Make sure GHCB is mapped before updating

Access to the GHCB is mainly in the VMGEXIT path and it is known that the
GHCB will be mapped. But there are two paths where it is possible the GHCB
might not be mapped.

The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform
the caller of the AP Reset Hold NAE event that a SIPI has been delivered.
However, if a SIPI is performed without a corresponding AP Reset Hold,
then the GHCB might not be mapped (depending on the previous VMEXIT),
which will result in a NULL pointer dereference.

The svm_complete_emulated_msr() routine will update the GHCB to inform
the caller of a RDMSR/WRMSR operation about any errors. While it is likely
that the GHCB will be mapped in this situation, add a safe guard
in this path to be certain a NULL pointer dereference is not encountered.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/a3ba26ecfb569f4aa3f867e80c02aa65f20aadad; https://git.kernel.org/stable/c/fb9e14f4f8217a0980f8da2c8ff70dee058cbe47; https://git.kernel.org/stable/c/fd722a57fe0b80133dacae4e1c852ee4212f9b2e
CVE: CVE-2021-47009
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

KEYS: trusted: Fix memory leak on object td

Two error return paths are neglecting to free allocated object td,
causing a memory leak. Fix this by returning via the error return
path that securely kfree's td.

Fixes clang scan-build warning:
security/keys/trusted-keys/trusted_tpm1.c:496:10: warning: Potential
memory leak [unix.Malloc]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/1c[PII_REDACTED]aff48e1e686e40101c31eab5d44c; https://git.kernel.org/stable/c/31c9a4b24d86cbb36ff0d7a085725a3b4f0138c8; https://git.kernel.org/stable/c/3e24fbd37e72e8a67b74991970fecc82d14f57af
CVE: CVE-2021-47010
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

net: Only allow init netns to set default tcp cong to a restricted algo

tcp_set_default_congestion_control() is netns-safe in that it writes
to &net->ipv4.tcp_congestion_control, but it also sets
ca->flags |= TCP_CONG_NON_RESTRICTED which is not namespaced.
This has the unintended side-effect of changing the global
net.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it
is read-only: 97684f0970f6 ("net: Make tcp_allowed_congestion_control
readonly in non-init netns")

Resolve this netns "leak" by only allowing the init netns to set the
default algorithm to one that is restricted. This restriction could be
removed if tcp_allowed_congestion_control were namespace-ified in the
future.

This bug was uncovered with
https://github.com/JonathonReinhart/linux-netns-sysctl-verify
CVSS Score: 7.8 (HIGH)
CWE: CWE-400
References: https://git.kernel.org/stable/c/6c1ea8bee75df8fe2184a50fcd0f70bf82986f42; https://git.kernel.org/stable/c/8d432592f30fcc34ef5a10aac4887b[PII_REDACTED]; https://git.kernel.org/stable/c/9884f745108f7d25b189bbcd6754e284fb29ab68
CVE: CVE-2021-47011
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

mm: memcontrol: slab: fix obtain a reference to a freeing memcg

Patch series "Use obj_cgroup APIs to charge kmem pages", v5.

Since Roman's series "The new cgroup slab memory controller" applied.
All slab objects are charged with the new APIs of obj_cgroup.  The new
APIs introduce a struct obj_cgroup to charge slab objects.  It prevents
long-living objects from pinning the original memory cgroup in the
memory.  But there are still some corner objects (e.g.  allocations
larger than order-1 page on SLUB) which are not charged with the new
APIs.  Those objects (include the pages which are allocated from buddy
allocator directly) are charged as kmem pages which still hold a
reference to the memory cgroup.

E.g.  We know that the kernel stack is charged as kmem pages because the
size of the kernel stack can be greater than 2 pages (e.g.  16KB on
x86_64 or arm64).  If we create a thread (suppose the thread stack is
charged to memory cgroup A) and then move it from memory cgroup A to
memory cgroup B.  Because the kernel stack of the thread hold a
reference to the memory cgroup A.  The thread can pin the memory cgroup
A in the memory even if we remove the cgroup A.  If we want to see this
scenario by using the following script.  We can see that the system has
added 500 dying cgroups (This is not a real world issue, just a script
to show that the large kmallocs are charged as kmem pages which can pin
the memory cgroup in the memory).

	#!/bin/bash

	cat /proc/cgroups | grep memory

	cd /sys/fs/cgroup/memory
	echo 1 > memory.move_charge_at_immigrate

	for i in range{1..500}
	do
		mkdir kmem_test
		echo $$ > kmem_test/cgroup.procs
		sleep 3600 &
		echo $$ > cgroup.procs
		echo `cat kmem_test/cgroup.procs` > cgroup.procs
		rmdir kmem_test
	done

	cat /proc/cgroups | grep memory

This patchset aims to make those kmem pages to drop the reference to
memory cgroup by using the APIs of obj_cgroup.  Finally, we can see that
the number of the dying cgroups will not increase if we run the above test
script.

This patch (of 7):

The rcu_read_lock/unlock only can guarantee that the memcg will not be
freed, but it cannot guarantee the success of css_get (which is in the
refill_stock when cached memcg changed) to memcg.

  rcu_read_lock()
  memcg = obj_cgroup_memcg(old)
  __memcg_kmem_uncharge(memcg)
      refill_stock(memcg)
          if (stock->cached != memcg)
              // css_get can change the ref counter from 0 back to 1.
              css_get(&memcg->css)
  rcu_read_unlock()

This fix is very like the commit:

  eefbfa7fd678 ("mm: memcg/slab: fix use after free in obj_cgroup_charge")

Fix this by holding a reference to the memcg which is passed to the
__memcg_kmem_uncharge() before calling __memcg_kmem_uncharge().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/31df8bc4d3feca9f9c6b2cd06fd64a111ae1a0e6; https://git.kernel.org/stable/c/89b1ed358e01e1b0417f5d3b0082359a23355552; https://git.kernel.org/stable/c/9f38f03ae8d5f57371b71aa6b4275765b65454fd
CVE: CVE-2021-47012
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/siw: Fix a use after free in siw_alloc_mr

Our code analyzer reported a UAF.

In siw_alloc_mr(), it calls siw_mr_add_mem(mr,..). In the implementation of
siw_mr_add_mem(), mem is assigned to mr->mem and then mem is freed via
kfree(mem) if xa_alloc_cyclic() failed. Here, mr->mem still point to a
freed object. After, the execution continue up to the err_out branch of
siw_alloc_mr, and the freed mr->mem is used in siw_mr_drop_mem(mr).

My patch moves "mr->mem = mem" behind the if (xa_alloc_cyclic(..)<0) {}
section, to avoid the uaf.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3093ee182f01689b89e9f8797b321603e5de4f63; https://git.kernel.org/stable/c/30b9e92d0b5e5d5dc1101ab856c17009537cbca4; https://git.kernel.org/stable/c/3e22b88e02c194f6c80867abfef5cc09383461f4
CVE: CVE-2021-47013
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send

In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..).
If some error happens in emac_tx_fill_tpd(), the skb will be freed via
dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd().
But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len).

As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len,
thus my patch assigns skb->len to 'len' before the possible free and
use 'len' instead of skb->len later.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/16d8c44be52e[PII_REDACTED]d45f5904384a9da834; https://git.kernel.org/stable/c/55fcdd1258faaecca74b91b88cc0921f9edd775d; https://git.kernel.org/stable/c/6d72e7c767acbbdd44ebc7d89c6690b405b32b57
CVE: CVE-2021-47014
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

net/sched: act_ct: fix wild memory access when clearing fragments

while testing re-assembly/re-fragmentation using act_ct, it's possible to
observe a crash like the following one:

 KASAN: maybe wild-memory-access in range [0x[PII_REDACTED]000448-0x[PII_REDACTED]00044f]
 CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S                5.12.0-rc7+ #424
 Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017
 RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0
 Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48
 RSP: 0018:ffff888c31449db8 EFLAGS: 00010203
 RAX: [PII_REDACTED] RBX:[PII_REDACTED]00040e RCX: ffffffff989eb960
 RDX: [PII_REDACTED] RSI: ffffffff97cfb977 RDI:[PII_REDACTED]00044e
 RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: ffffed[PII_REDACTED]
 R10: [PII_REDACTED] R11: ffffed[PII_REDACTED] R12: dffffc[PII_REDACTED]
 R13:[PII_REDACTED]00040e R14: [PII_REDACTED] R15: ffff888155e02160
 FS:  [PII_REDACTED](0000) GS:ffff888c31440000(0000) knlGS:[PII_REDACTED]
 CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4:[PII_REDACTED]3706e0
 DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
 DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
 Call Trace:
  <IRQ>
  inet_frag_destroy+0xa9/0x150
  call_timer_fn+0x2d/0x180
  run_timer_softirq+0x4fe/0xe70
  __do_softirq+0x197/0x5a0
  irq_exit_rcu+0x1de/0x200
  sysvec_apic_timer_interrupt+0x6b/0x80
  </IRQ>

when act_ct temporarily stores an IP fragment, restoring the skb qdisc cb
results in putting random data in FRAG_CB(), and this causes those "wild"
memory accesses later, when the rbtree is purged. Never overwrite the skb
cb in case tcf_ct_handle_fragments() returns -EINPROGRESS.
CVSS Score: 7.8 (HIGH)
CWE: CWE-754
References: https://git.kernel.org/stable/c/0648941f4c8bbf8b4b6c0b270889ae7aa769b921; https://git.kernel.org/stable/c/f77bd544a6bbe69aa50d9ed09f13494cf36ff806; https://git.kernel.org/stable/c/0648941f4c8bbf8b4b6c0b270889ae7aa769b921
CVE: CVE-2021-47015
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

bnxt_en: Fix RX consumer index logic in the error path.

In bnxt_rx_pkt(), the RX buffers are expected to complete in order.
If the RX consumer index indicates an out of order buffer completion,
it means we are hitting a hardware bug and the driver will abort all
remaining RX packets and reset the RX ring.  The RX consumer index
that we pass to bnxt_discard_rx() is not correct.  We should be
passing the current index (tmp_raw_cons) instead of the old index
(raw_cons).  This bug can cause us to be at the wrong index when
trying to abort the next RX packet.  It can crash like this:

 #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007
 #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232
 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e
 #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978
 #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0
 #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e
 #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24
 #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e
 #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12
 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5
    [exception RIP: bnxt_rx_pkt+237]
    RIP: ffffffffc0259cdd  RSP: ffff9bbcdf5c3d98  RFLAGS: 00010213
    RAX: 000000005dd8097f  RBX: ffff9ba4cb11b7e0  RCX: ffffa923cf6e9000
    RDX:[PII_REDACTED]000fff  RSI: [PII_REDACTED]  RDI: [PII_REDACTED]
    RBP: ffff9bbcdf5c3e60   R8: [PII_REDACTED]   R9:[PII_REDACTED]00020d
    R10: ffffa923cf6ec138  R11: ffff9bbcdf5c3e83  R12: ffff9ba4d6f928c0
    R13: ffff9ba4cac28080  R14: ffff9ba4cb11b7f0  R15: ffff9ba4d5a30000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3fbc5bc651d688fbea2a59cdc91520a2f5334d0a; https://git.kernel.org/stable/c/4fcaad2b7dac3f16704f8118c7e481024ddbd3ed; https://git.kernel.org/stable/c/b1523e4ba293b2a32d9fabaf70c1dcaa6e3e2847
CVE: CVE-2021-47017
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

ath10k: Fix a use after free in ath10k_htc_send_bundle

In ath10k_htc_send_bundle, the bundle_skb could be freed by
dev_kfree_skb_any(bundle_skb). But the bundle_skb is used later
by bundle_skb->len.

As skb_len = bundle_skb->len, my patch replaces bundle_skb->len to
skb_len after the bundle_skb was freed.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3b1ac40c[PII_REDACTED]caa79e592a438a18ebf71b; https://git.kernel.org/stable/c/5e413c0831ff4700d1739db3fa3ae9f859744676; https://git.kernel.org/stable/c/8392df5d7e0b6a7d21440da1fc259f9938f4dec3
CVE: CVE-2021-47018
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/64: Fix the definition of the fixmap area

At the time being, the fixmap area is defined at the top of
the address space or just below KASAN.

This definition is not valid for PPC64.

For PPC64, use the top of the I/O space.

Because of circular dependencies, it is not possible to include
asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size
AREA at the top of the I/O space for fixmap and ensure during
build that the size is big enough.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/4b9fb2c9039a206d37f215936a4d5bee7b1bf9cd; https://git.kernel.org/stable/c/9ccba66d4d2aff9a3909aa77d57ea8b7cc166f3c; https://git.kernel.org/stable/c/a84df7c80bdac598d6ac9268ae578da6928883e8
CVE: CVE-2021-47019
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7921: fix possible invalid register access

Disable the interrupt and synchronze for the pending irq handlers to ensure
the irq tasklet is not being scheduled after the suspend to avoid the
possible invalid register access acts when the host pcie controller is
suspended.

[17932.910534] mt7921e 0000:01:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 21375 usecs
[17932.910590] pcieport 0000:00:00.0: calling pci_pm_suspend+0x0/0x22c @ 18565, parent: pci0000:00
[17932.910602] pcieport 0000:00:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 8 usecs
[17932.910671] mtk-pcie 11230000.pcie: calling platform_pm_suspend+0x0/0x60 @ 22783, parent: soc
[17932.910674] mtk-pcie 11230000.pcie: platform_pm_suspend+0x0/0x60 returned 0 after 0 usecs

...

17933.615352] x1 :[PII_REDACTED]0d4200 x0 : ffffff8269ca2300
[17933.620666] Call trace:
[17933.623127]  mt76_mmio_rr+0x28/0xf0 [mt76]
[17933.627234]  mt7921_rr+0x38/0x44 [mt7921e]
[17933.631339]  mt7921_irq_tasklet+0x54/0x1d8 [mt7921e]
[17933.636309]  tasklet_action_common+0x12c/0x16c
[17933.640754]  tasklet_action+0x24/0x2c
[17933.644418]  __do_softirq+0x16c/0x344
[17933.648082]  irq_exit+0xa8/0xac
[17933.651224]  scheduler_ipi+0xd4/0x148
[17933.654890]  handle_IPI+0x164/0x2d4
[17933.658379]  gic_handle_irq+0x140/0x178
[17933.662216]  el1_irq+0xb8/0x180
[17933.665361]  cpuidle_enter_state+0xf8/0x204
[17933.669544]  cpuidle_enter+0x38/0x4c
[17933.673122]  do_idle+0x1a4/0x2a8
[17933.676352]  cpu_startup_entry+0x24/0x28
[17933.680276]  rest_init+0xd4/0xe0
[17933.683508]  arch_call_rest_init+0x10/0x18
[17933.687606]  start_kernel+0x340/0x3b4
[17933.691279] Code: aa0003f5 d503201f f953eaa8 8b344108 (b9400113)
[17933.697373] ---[ end trace a24b8e26ffbda3c5 ]---
[17933.767846] Kernel panic - not syncing: Fatal exception in interrupt
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/b13cbc536990ff609afa878b6211cd6f6265ba60; https://git.kernel.org/stable/c/fe3fccde8870764ba3e60610774bd7bc9f8faeff; https://git.kernel.org/stable/c/b13cbc536990ff609afa878b6211cd6f6265ba60
CVE: CVE-2021-47021
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7915: fix memleak when mt7915_unregister_device()

mt7915_tx_token_put() should get call before mt76_free_pending_txwi().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/81483309ce861a9fa[PII_REDACTED]f68a443fea364; https://git.kernel.org/stable/c/d754c80ae82a662e692a82faad71b8c218cb7f52; https://git.kernel.org/stable/c/e9d32af478cfc3744a45245c0b126738af4b3ac4
CVE: CVE-2021-47022
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7615: fix memleak when mt7615_unregister_device()

mt7615_tx_token_put() should get call before mt76_free_pending_txwi().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/107bcbb219ac84d885ac63b25246f8d33212bc47; https://git.kernel.org/stable/c/4fa28c807da54c1d720b3cc12e48eb9bea1e2c8f; https://git.kernel.org/stable/c/6c5b2b0c6e5a6ce2d8f9f85b8b72bfad60eaa506