alirezaaminzadeh/cve-riskrank huggingface dataset:
CVE-2021-46995 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

can: mcp251xfd: mcp251xfd_probe(): fix an error pointer dereference in probe

When we converted this code to use dev_err_probe() we accidentally
removed a return. It means that if devm_clk_get() it will lead to an
Oops when we call clk_get_rate() on the next line.
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-476
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-46996 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftables: Fix a memleak from userdata error path in new objects

Release object name if userdata allocation fails.
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-401
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-46998 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

ethernet:enic: Fix a use after free bug in enic_hard_start_xmit

In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside
enic_queue_wq_skb, if some error happens, the skb will be freed
by dev_kfree_skb(skb). But the freed skb is still used in
skb_tx_timestamp(skb).

My patch makes enic_queue_wq_skb() return error and goto spin_unlock()
incase of error. The solution is provided by Govind.
See https://lkml.org/lkml/2021/4/30/961.
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Weakness: CWE-416
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-46999 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

sctp: do asoc update earlier in sctp_sf_do_dupcook_a

There's a panic that occurs in a few of envs, the call trace is as below:

  [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI
  [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp]
  []  sctp_assoc_control_transport+0x1b9/0x210 [sctp]
  []  sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp]
  []  sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp]
  []  sctp_do_sm+0xc3/0x2a0 [sctp]
  []  sctp_generate_timeout_event+0x81/0xf0 [sctp]

This is caused by a transport use-after-free issue. When processing a
duplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK
and SHUTDOWN chunks are allocated with the transort from the new asoc.
However, later in the sideeffect machine, the old asoc is used to send
them out and old asoc's shutdown_last_sent_to is set to the transport
that SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually
belongs to the new asoc. After the new_asoc is freed and the old asoc
T2 timeout, the old asoc's shutdown_last_sent_to that is already freed
would be accessed in sctp_sf_t2_timer_expire().

Thanks Alexander and Jere for helping dig into this issue.

To fix it, this patch is to do the asoc update first, then allocate
the COOKIE-ACK and SHUTDOWN chunks with the 'updated' old asoc. This
would make more sense, as a chunk from an asoc shouldn't be sent out
with another asoc. We had fixed quite a few issues caused by this.
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Weakness: CWE-416
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47000 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

ceph: fix inode leak on getattr error in __fh_to_dentry
Severity: LOW (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47001 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

xprtrdma: Fix cwnd update ordering

After a reconnect, the reply handler is opening the cwnd (and thus
enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs()
can post enough Receive WRs to receive their replies. This causes an
RNR and the new connection is lost immediately.

The race is most clearly exposed when KASAN and disconnect injection
are enabled. This slows down rpcrdma_rep_create() enough to allow
the send side to post a bunch of RPC Calls before the Receive
completion handler can invoke ib_post_recv().
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47002 (published 2024-02-28)
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")
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-476
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47003 (published 2024-02-28)
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")
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-476
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47004 (published 2024-02-28)
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.
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47005 (published 2024-02-28)
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 ]---
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-476
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47006 (published 2024-02-28)
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/20210207105934.2001-1-thunder.leizhen@huawei.com/
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47007 (published 2024-02-28)
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().
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-754
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47008 (published 2024-02-28)
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.
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-476
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47009 (published 2024-02-28)
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]
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-401
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47010 (published 2024-02-28)
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
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Weakness: CWE-400
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47011 (published 2024-02-28)
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().
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47012 (published 2024-02-28)
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.
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Weakness: CWE-416
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47013 (published 2024-02-28)
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.
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Weakness: CWE-416
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47014 (published 2024-02-28)
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 [0x0001000000000448-0x000100000000044f]
 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: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960
 RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e
 RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350
 R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000
 R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160
 FS:  0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 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.
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Weakness: CWE-754
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47015 (published 2024-02-28)
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: 0000000000000fff  RSI: 0000000000000627  RDI: 0000000000001000
    RBP: ffff9bbcdf5c3e60   R8: 0000000000420003   R9: 000000000000020d
    R10: ffffa923cf6ec138  R11: ffff9bbcdf5c3e83  R12: ffff9ba4d6f928c0
    R13: ffff9ba4cac28080  R14: ffff9ba4cb11b7f0  R15: ffff9ba4d5a30000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47016 (published 2024-02-29)
In the Linux kernel, the following vulnerability has been resolved:

m68k: mvme147,mvme16x: Don't wipe PCC timer config bits

Don't clear the timer 1 configuration bits when clearing the interrupt flag
and counter overflow. As Michael reported, "This results in no timer
interrupts being delivered after the first. Initialization then hangs
in calibrate_delay as the jiffies counter is not updated."

On mvme16x, enable the timer after requesting the irq, consistent with
mvme147.
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47017 (published 2024-02-28)
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.
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Weakness: CWE-416
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47018 (published 2024-02-28)
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.
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47019 (published 2024-02-28)
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 : 00000000000d4200 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
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47020 (published 2024-02-29)
In the Linux kernel, the following vulnerability has been resolved:

soundwire: stream: fix memory leak in stream config error path

When stream config is failed, master runtime will release all
slave runtime in the slave_rt_list, but slave runtime is not
added to the list at this time. This patch frees slave runtime
in the config error path to fix the memory leak.
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-401
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47021 (published 2024-02-28)
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().
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-401
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47022 (published 2024-02-28)
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().
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-401
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47024 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: free queued packets when closing socket

As reported by syzbot [1], there is a memory leak while closing the
socket. We partially solved this issue with commit ac03046ece2b
("vsock/virtio: free packets during the socket release"), but we
forgot to drain the RX queue when the socket is definitely closed by
the scheduled work.

To avoid future issues, let's use the new virtio_transport_remove_sock()
to drain the RX queue before removing the socket from the af_vsock lists
calling vsock_remove_sock().

[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-401
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47025 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

iommu/mediatek: Always enable the clk on resume

In mtk_iommu_runtime_resume always enable the clk, even
if m4u_dom is null. Otherwise the 'suspend' cb might
disable the clk which is already disabled causing the warning:

[    1.586104] infra_m4u already disabled
[    1.586133] WARNING: CPU: 0 PID: 121 at drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8
[    1.594391] mtk-iommu 10205000.iommu: bound 18001000.larb (ops mtk_smi_larb_component_ops)
[    1.598108] Modules linked in:
[    1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 5.12.0-rc5 #69
[    1.609246] mtk-iommu 10205000.iommu: bound 14027000.larb (ops mtk_smi_larb_component_ops)
[    1.617487] Hardware name: Google Elm (DT)
[    1.617491] Workqueue: pm pm_runtime_work
[    1.620545] mtk-iommu 10205000.iommu: bound 19001000.larb (ops mtk_smi_larb_component_ops)

[    1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[    1.659297] pc : clk_core_disable+0xb0/0xb8
[    1.663475] lr : clk_core_disable+0xb0/0xb8
[    1.667652] sp : ffff800011b9bbe0
[    1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000
[    1.676267] x27: ffff800011448000 x26: ffff8000100cfd98
[    1.681574] x25: ffff800011b9bd48 x24: 0000000000000000
[    1.686882] x23: 0000000000000000 x22: ffff8000106fad90
[    1.692189] x21: 000000000000000a x20: ffff0000c0048500
[    1.697496] x19: ffff0000c0048500 x18: ffffffffffffffff
[    1.702804] x17: 0000000000000000 x16: 0000000000000000
[    1.708112] x15: ffff800011460300 x14: fffffffffffe0000
[    1.713420] x13: ffff8000114602d8 x12: 0720072007200720
[    1.718727] x11: 0720072007200720 x10: 0720072007200720
[    1.724035] x9 : ffff800011b9bbe0 x8 : ffff800011b9bbe0
[    1.729342] x7 : 0000000000000009 x6 : ffff8000114b8328
[    1.734649] x5 : 0000000000000000 x4 : 0000000000000000
[    1.739956] x3 : 00000000ffffffff x2 : ffff800011460298
[    1.745263] x1 : 1af1d7de276f4500 x0 : 0000000000000000
[    1.750572] Call trace:
[    1.753010]  clk_core_disable+0xb0/0xb8
[    1.756840]  clk_core_disable_lock+0x24/0x40
[    1.761105]  clk_disable+0x20/0x30
[    1.764501]  mtk_iommu_runtime_suspend+0x88/0xa8
[    1.769114]  pm_generic_runtime_suspend+0x2c/0x48
[    1.773815]  __rpm_callback+0xe0/0x178
[    1.777559]  rpm_callback+0x24/0x88
[    1.781041]  rpm_suspend+0xdc/0x470
[    1.784523]  rpm_idle+0x12c/0x170
[    1.787831]  pm_runtime_work+0xa8/0xc0
[    1.791573]  process_one_work+0x1e8/0x360
[    1.795580]  worker_thread+0x44/0x478
[    1.799237]  kthread+0x150/0x158
[    1.802460]  ret_from_fork+0x10/0x30
[    1.806034] ---[ end trace 82402920ef64573b ]---
[    1.810728] ------------[ cut here ]------------

In addition, we now don't need to enable the clock from the
function mtk_iommu_hw_init since it is already enabled by the resume.
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47026 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

RDMA/rtrs-clt: destroy sysfs after removing session from active list

A session can be removed dynamically by sysfs interface "remove_path" that
eventually calls rtrs_clt_remove_path_from_sysfs function.  The current
rtrs_clt_remove_path_from_sysfs first removes the sysfs interfaces and
frees sess->stats object. Second it removes the session from the active
list.

Therefore some functions could access non-connected session and access the
freed sess->stats object even-if they check the session status before
accessing the session.

For instance rtrs_clt_request and get_next_path_min_inflight check the
session status and try to send IO to the session.  The session status
could be changed when they are trying to send IO but they could not catch
the change and update the statistics information in sess->stats object,
and generate use-after-free problem.
(see: "RDMA/rtrs-clt: Check state of the rtrs_clt_sess before reading its
stats")

This patch changes the rtrs_clt_remove_path_from_sysfs to remove the
session from the active session list and then destroy the sysfs
interfaces.

Each function still should check the session status because closing or
error recovery paths can change the status.
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Weakness: CWE-416
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47027 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7921: fix kernel crash when the firmware fails to download

Fix kernel crash when the firmware is missing or fails to download.

[    9.444758] kernel BUG at drivers/pci/msi.c:375!
[    9.449363] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[    9.501033] pstate: a0400009 (NzCv daif +PAN -UAO)
[    9.505814] pc : free_msi_irqs+0x180/0x184
[    9.509897] lr : free_msi_irqs+0x40/0x184
[    9.513893] sp : ffffffc015193870
[    9.517194] x29: ffffffc015193870 x28: 00000000f0e94fa2
[    9.522492] x27: 0000000000000acd x26: 000000000000009a
[    9.527790] x25: ffffffc0152cee58 x24: ffffffdbb383e0d8
[    9.533087] x23: ffffffdbb38628d0 x22: 0000000000040200
[    9.538384] x21: ffffff8cf7de7318 x20: ffffff8cd65a2480
[    9.543681] x19: ffffff8cf7de7000 x18: 0000000000000000
[    9.548979] x17: ffffff8cf9ca03b4 x16: ffffffdc13ad9a34
[    9.554277] x15: 0000000000000000 x14: 0000000000080800
[    9.559575] x13: ffffff8cd65a2980 x12: 0000000000000000
[    9.564873] x11: ffffff8cfa45d820 x10: ffffff8cfa45d6d0
[    9.570171] x9 : 0000000000000040 x8 : ffffff8ccef1b780
[    9.575469] x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000000
[    9.580766] x5 : ffffffdc13824900 x4 : ffffff8ccefe0000
[    9.586063] x3 : 0000000000000000 x2 : 0000000000000000
[    9.591362] x1 : 0000000000000125 x0 : ffffff8ccefe0000
[    9.596660] Call trace:
[    9.599095]  free_msi_irqs+0x180/0x184
[    9.602831]  pci_disable_msi+0x100/0x130
[    9.606740]  pci_free_irq_vectors+0x24/0x30
[    9.610915]  mt7921_pci_probe+0xbc/0x250 [mt7921e]
[    9.615693]  pci_device_probe+0xd4/0x14c
[    9.619604]  really_probe+0x134/0x2ec
[    9.623252]  driver_probe_device+0x64/0xfc
[    9.627335]  device_driver_attach+0x4c/0x6c
[    9.631506]  __driver_attach+0xac/0xc0
[    9.635243]  bus_for_each_dev+0x8c/0xd4
[    9.639066]  driver_attach+0x2c/0x38
[    9.642628]  bus_add_driver+0xfc/0x1d0
[    9.646365]  driver_register+0x64/0xf8
[    9.650101]  __pci_register_driver+0x6c/0x7c
[    9.654360]  init_module+0x28/0xfdc [mt7921e]
[    9.658704]  do_one_initcall+0x13c/0x2d0
[    9.662615]  do_init_module+0x58/0x1e8
[    9.666351]  load_module+0xd80/0xeb4
[    9.669912]  __arm64_sys_finit_module+0xa8/0xe0
[    9.674430]  el0_svc_common+0xa4/0x16c
[    9.678168]  el0_svc_compat_handler+0x2c/0x40
[    9.682511]  el0_svc_compat+0x8/0x10
[    9.686076] Code: a94257f6 f9400bf7 a8c47bfd d65f03c0 (d4210000)
[    9.692155] ---[ end trace 7621f966afbf0a29 ]---
[    9.697385] Kernel panic - not syncing: Fatal exception
[    9.702599] SMP: stopping secondary CPUs
[    9.706549] Kernel Offset: 0x1c03600000 from 0xffffffc010000000
[    9.712456] PHYS_OFFSET: 0xfffffff440000000
[    9.716625] CPU features: 0x080026,2a80aa18
[    9.720795] Memory Limit: none
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47028 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7915: fix txrate reporting

Properly check rate_info to fix unexpected reporting.

[ 1215.161863] Call trace:
[ 1215.164307]  cfg80211_calculate_bitrate+0x124/0x200 [cfg80211]
[ 1215.170139]  ieee80211s_update_metric+0x80/0xc0 [mac80211]
[ 1215.175624]  ieee80211_tx_status_ext+0x508/0x838 [mac80211]
[ 1215.181190]  mt7915_mcu_get_rx_rate+0x28c/0x8d0 [mt7915e]
[ 1215.186580]  mt7915_mac_tx_free+0x324/0x7c0 [mt7915e]
[ 1215.191623]  mt7915_queue_rx_skb+0xa8/0xd0 [mt7915e]
[ 1215.196582]  mt76_dma_cleanup+0x7b0/0x11d0 [mt76]
[ 1215.201276]  __napi_poll+0x38/0xf8
[ 1215.204668]  napi_workfn+0x40/0x80
[ 1215.208062]  process_one_work+0x1fc/0x390
[ 1215.212062]  worker_thread+0x48/0x4d0
[ 1215.215715]  kthread+0x120/0x128
[ 1215.218935]  ret_from_fork+0x10/0x1c
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47029 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

mt76: connac: fix kernel warning adding monitor interface

Fix the following kernel warning adding a monitor interface in
mt76_connac_mcu_uni_add_dev routine.

[  507.984882] ------------[ cut here ]------------
[  507.989515] WARNING: CPU: 1 PID: 3017 at mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]
[  508.059379] CPU: 1 PID: 3017 Comm: ifconfig Not tainted 5.4.98 #0
[  508.065461] Hardware name: MT7622_MT7531 RFB (DT)
[  508.070156] pstate: 80000005 (Nzcv daif -PAN -UAO)
[  508.074939] pc : mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]
[  508.081806] lr : mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e]
[  508.087367] sp : ffffffc013a33930
[  508.090671] x29: ffffffc013a33930 x28: ffffff801e628ac0
[  508.095973] x27: ffffff801c7f1200 x26: ffffff801c7eb008
[  508.101275] x25: ffffff801c7eaef0 x24: ffffff801d025610
[  508.106577] x23: ffffff801d022990 x22: ffffff801d024de8
[  508.111879] x21: ffffff801d0226a0 x20: ffffff801c7eaee8
[  508.117181] x19: ffffff801d0226a0 x18: 000000005d00b000
[  508.122482] x17: 00000000ffffffff x16: 0000000000000000
[  508.127785] x15: 0000000000000080 x14: ffffff801d704000
[  508.133087] x13: 0000000000000040 x12: 0000000000000002
[  508.138389] x11: 000000000000000c x10: 0000000000000000
[  508.143691] x9 : 0000000000000020 x8 : 0000000000000001
[  508.148992] x7 : 0000000000000000 x6 : 0000000000000000
[  508.154294] x5 : ffffff801c7eaee8 x4 : 0000000000000006
[  508.159596] x3 : 0000000000000001 x2 : 0000000000000000
[  508.164898] x1 : ffffff801c7eac08 x0 : ffffff801d0226a0
[  508.170200] Call trace:
[  508.172640]  mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]
[  508.179159]  mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e]
[  508.184394]  drv_add_interface+0x34/0x88 [mac80211]
[  508.189271]  ieee80211_add_virtual_monitor+0xe0/0xb48 [mac80211]
[  508.195277]  ieee80211_do_open+0x86c/0x918 [mac80211]
[  508.200328]  ieee80211_do_open+0x900/0x918 [mac80211]
[  508.205372]  __dev_open+0xcc/0x150
[  508.208763]  __dev_change_flags+0x134/0x198
[  508.212937]  dev_change_flags+0x20/0x60
[  508.216764]  devinet_ioctl+0x3e8/0x748
[  508.220503]  inet_ioctl+0x1e4/0x350
[  508.223983]  sock_do_ioctl+0x48/0x2a0
[  508.227635]  sock_ioctl+0x310/0x4f8
[  508.231116]  do_vfs_ioctl+0xa4/0xac0
[  508.234681]  ksys_ioctl+0x44/0x90
[  508.237985]  __arm64_sys_ioctl+0x1c/0x48
[  508.241901]  el0_svc_common.constprop.1+0x7c/0x100
[  508.246681]  el0_svc_handler+0x18/0x20
[  508.250421]  el0_svc+0x8/0x1c8
[  508.253465] ---[ end trace c7b90fee13d72c39 ]---
[  508.261278] ------------[ cut here ]------------
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47030 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7615: fix memory leak in mt7615_coredump_work

Similar to the issue fixed in mt7921_coredump_work, fix a possible memory
leak in mt7615_coredump_work routine.
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-401
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47031 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7921: fix memory leak in mt7921_coredump_work

Fix possible memory leak in mt7921_coredump_work.
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)
Weakness: CWE-401
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47032 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7915: fix tx skb dma unmap

The first pointer in the txp needs to be unmapped as well, otherwise it will
leak DMA mapping entries
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-401
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47033 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

mt76: mt7615: fix tx skb dma unmap

The first pointer in the txp needs to be unmapped as well, otherwise it will
leak DMA mapping entries
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-401
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47035 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Remove WO permissions on second-level paging entries

When the first level page table is used for IOVA translation, it only
supports Read-Only and Read-Write permissions. The Write-Only permission
is not supported as the PRESENT bit (implying Read permission) should
always set. When using second level, we still give separate permissions
that allows WriteOnly which seems inconsistent and awkward. We want to
have consistent behavior. After moving to 1st level, we don't want things
to work sometimes, and break if we use 2nd level for the same mappings.
Hence remove this configuration.
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47036 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

udp: skip L4 aggregation for UDP tunnel packets

If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there
are UDP tunnels available in the system, udp_gro_receive() could end-up
doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at
the outer UDP tunnel level for packets effectively carrying and UDP
tunnel header.

That could cause inner protocol corruption. If e.g. the relevant
packets carry a vxlan header, different vxlan ids will be ignored/
aggregated to the same GSO packet. Inner headers will be ignored, too,
so that e.g. TCP over vxlan push packets will be held in the GRO
engine till the next flush, etc.

Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the
current packet could land in a UDP tunnel, and let udp_gro_receive()
do GRO via udp_sk(sk)->gro_receive.

The check implemented in this patch is broader than what is strictly
needed, as the existing UDP tunnel could be e.g. configured on top of
a different device: we could end-up skipping GRO at-all for some packets.

Anyhow, that is a very thin corner case and covering it will add quite
a bit of complexity.

v1 -> v2:
 - hopefully clarify the commit message
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47037 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

ASoC: q6afe-clocks: fix reprobing of the driver

Q6afe-clocks driver can get reprobed. For example if the APR services
are restarted after the firmware crash. However currently Q6afe-clocks
driver will oops because hw.init will get cleared during first _probe
call. Rewrite the driver to fill the clock data at runtime rather than
using big static array of clocks.
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47039 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

ataflop: potential out of bounds in do_format()

The function uses "type" as an array index:

	q = unit[drive].disk[type]->queue;

Unfortunately the bounds check on "type" isn't done until later in the
function.  Fix this by moving the bounds check to the start.
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Weakness: CWE-125
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47040 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

io_uring: fix overflows checks in provide buffers

Colin reported before possible overflow and sign extension problems in
io_provide_buffers_prep(). As Linus pointed out previous attempt did nothing
useful, see d81269fecb8ce ("io_uring: fix provide_buffers sign extension").

Do that with help of check_<op>_overflow helpers. And fix struct
io_provide_buf::len type, as it doesn't make much sense to keep it
signed.
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Weakness: CWE-120
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47042 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Free local data after use

Fixes the following memory leak in dc_link_construct():

unreferenced object 0xffffa03e81471400 (size 1024):
comm "amd_module_load", pid 2486, jiffies 4294946026 (age 10.544s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000000bdf5c4a>] kmem_cache_alloc_trace+0x30a/0x4a0
[<00000000e7c59f0e>] link_create+0xce/0xac0 [amdgpu]
[<000000002fb6c072>] dc_create+0x370/0x720 [amdgpu]
[<000000000094d1f3>] amdgpu_dm_init+0x18e/0x17a0 [amdgpu]
[<00000000bec048fd>] dm_hw_init+0x12/0x20 [amdgpu]
[<00000000a2bb7cf6>] amdgpu_device_init+0x1463/0x1e60 [amdgpu]
[<0000000032d3bb13>] amdgpu_driver_load_kms+0x5b/0x330 [amdgpu]
[<00000000a27834f9>] amdgpu_pci_probe+0x192/0x280 [amdgpu]
[<00000000fec7d291>] local_pci_probe+0x47/0xa0
[<0000000055dbbfa7>] pci_device_probe+0xe3/0x180
[<00000000815da970>] really_probe+0x1c4/0x4e0
[<00000000b4b6974b>] driver_probe_device+0x62/0x150
[<000000000f9ecc61>] device_driver_attach+0x58/0x60
[<000000000f65c843>] __driver_attach+0xd6/0x150
[<000000002f5e3683>] bus_for_each_dev+0x6a/0xc0
[<00000000a1cfc897>] driver_attach+0x1e/0x20
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Weakness: CWE-401
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47043 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

media: venus: core: Fix some resource leaks in the error path of 'venus_probe()'

If an error occurs after a successful 'of_icc_get()' call, it must be
undone.

Use 'devm_of_icc_get()' instead of 'of_icc_get()' to avoid the leak.
Update the remove function accordingly and axe the now unneeded
'icc_put()' calls.
Severity: MEDIUM (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Affected vendors: linux
Affected products: linux_kernel
CVE-2021-47044 (published 2024-02-28)
In the Linux kernel, the following vulnerability has been resolved:

sched/fair: Fix shift-out-of-bounds in load_balance()

Syzbot reported a handful of occurrences where an sd->nr_balance_failed can
grow to much higher values than one would expect.

A successful load_balance() resets it to 0; a failed one increments
it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an
active balance, which will either set it to sd->cache_nice_tries+1 or reset
it to 0. However, in case the to-be-active-balanced task is not allowed to
run on env->dst_cpu, then the increment is done without any further
modification.

This could then be repeated ad nauseam, and would explain the absurdly high
values reported by syzbot (86, 149). VincentG noted there is value in
letting sd->cache_nice_tries grow, so the shift itself should be
fixed. That means preventing:

  """
  If the value of the right operand is negative or is greater than or equal
  to the width of the promoted left operand, the behavior is undefined.
  """

Thus we need to cap the shift exponent to
  BITS_PER_TYPE(typeof(lefthand)) - 1.

I had a look around for other similar cases via coccinelle:

  @expr@
  position pos;
  expression E1;
  expression E2;
  @@
  (
  E1 >> E2@pos
  |
  E1 >> E2@pos
  )

  @cst depends on expr@
  position pos;
  expression expr.E1;
  constant cst;
  @@
  (
  E1 >> cst@pos
  |
  E1 << cst@pos
  )

  @script:python depends on !cst@
  pos << expr.pos;
  exp << expr.E2;
  @@
  # Dirty hack to ignore constexpr
  if exp.upper() != exp:
     coccilib.report.print_report(pos[0], "Possible UB shift here")

The only other match in kernel/sched is rq_clock_thermal() which employs
sched_thermal_decay_shift, and that exponent is already capped to 10, so
that one is fine.
Severity: HIGH (CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H)
Weakness: CWE-125
Affected vendors: linux
Affected products: linux_kernel