deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2021-47377
Published: 2024-05-21
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2021-47378
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

nvme-rdma: destroy cm id before destroy qp to avoid use after free

We should always destroy cm_id before destroy qp to avoid to get cma
event after qp was destroyed, which may lead to use after free.
In RDMA connection establishment error flow, don't destroy qp in cm
event handler.Just report cm_error to upper level, qp will be destroy
in nvme_rdma_alloc_queue() after destroy cm id.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-416
References: https://git.kernel.org/stable/c/9817d763dbe15327b9b3ff4404fa6f27f927e744; https://git.kernel.org/stable/c/d268a182c56e8361e19fb[PII_REDACTED]43312b994; https://git.kernel.org/stable/c/ecf0dc5a904830c926a64feffd8e01141f89822f
CVE: CVE-2021-47380
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

HID: amd_sfh: Fix potential NULL pointer dereference

devm_add_action_or_reset() can suddenly invoke amd_mp2_pci_remove() at
registration that will cause NULL pointer dereference since
corresponding data is not initialized yet. The patch moves
initialization of data before devm_add_action_or_reset().

Found by Linux Driver Verification project (linuxtesting.org).

[jkosina@suse.cz: rebase]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/283e4bee701dfcd409dd293f19a268bb2bc8ff38; https://git.kernel.org/stable/c/d46ef750ed58cbeeba2d9a55c99231c30a172764; https://git.kernel.org/stable/c/283e4bee701dfcd409dd293f19a268bb2bc8ff38
CVE: CVE-2021-47381
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: Fix DSP oops stack dump output contents

Fix @buf arg given to hex_dump_to_buffer() and stack address used
in dump error output.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-209
References: https://git.kernel.org/stable/c/a6bb576ead074ca6fa3b53cb1c5d4037a23de81b; https://git.kernel.org/stable/c/ac4dfccb96571ca03af7cac64b7a0b2952c97f3a; https://git.kernel.org/stable/c/a6bb576ead074ca6fa3b53cb1c5d4037a23de81b
CVE: CVE-2021-47382
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/qeth: fix deadlock during failing recovery

Commit 0b9902c1fcc5 ("s390/qeth: fix deadlock during recovery") removed
taking discipline_mutex inside qeth_do_reset(), fixing potential
deadlocks. An error path was missed though, that still takes
discipline_mutex and thus has the original deadlock potential.

Intermittent deadlocks were seen when a qeth channel path is configured
offline, causing a race between qeth_do_reset and ccwgroup_remove.
Call qeth_set_offline() directly in the qeth_do_reset() error case and
then a new variant of ccwgroup_set_offline(), without taking
discipline_mutex.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-667
References: https://git.kernel.org/stable/c/0bfe[PII_REDACTED]22d1482c7edef0184636d08b40; https://git.kernel.org/stable/c/d2b59bd4b06d84a4eadb520b0f71c62fe8ec0a62; https://git.kernel.org/stable/c/0bfe[PII_REDACTED]22d1482c7edef0184636d08b40
CVE: CVE-2021-47383
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

tty: Fix out-of-bound vmalloc access in imageblit

This issue happens when a userspace program does an ioctl
FBIOPUT_VSCREENINFO passing the fb_var_screeninfo struct
containing only the fields xres, yres, and bits_per_pixel
with values.

If this struct is the same as the previous ioctl, the
vc_resize() detects it and doesn't call the resize_screen(),
leaving the fb_var_screeninfo incomplete. And this leads to
the updatescrollmode() calculates a wrong value to
fbcon_display->vrows, which makes the real_y() return a
wrong value of y, and that value, eventually, causes
the imageblit to access an out-of-bound address value.

To solve this issue I made the resize_screen() be called
even if the screen does not need any resizing, so it will
"fix and fill" the fb_var_screeninfo independently.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/067c694d06040db6f0c65281bb358452ca6d85b9; https://git.kernel.org/stable/c/3b0c406124719b625b1aba431659f5cdc24a982c; https://git.kernel.org/stable/c/699d926585daa6ec44be556cdc1ab89e5d54557b
CVE: CVE-2021-47384
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

hwmon: (w83793) Fix NULL pointer dereference by removing unnecessary structure field

If driver read tmp value sufficient for
(tmp & 0x08) && (!(tmp & 0x80)) && ((tmp & 0x7) == ((tmp >> 4) & 0x7))
from device then Null pointer dereference occurs.
(It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)
Also lm75[] does not serve a purpose anymore after switching to
devm_i2c_new_dummy_device() in w83791d_detect_subclients().

The patch fixes possible NULL pointer dereference by removing lm75[].

Found by Linux Driver Verification project (linuxtesting.org).

[groeck: Dropped unnecessary continuation lines, fixed multi-line alignments]
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/6cb01fe630eaffc5a2c3f7364436caddba286623; https://git.kernel.org/stable/c/746011193f44f97f8784edcf8327c587946745fc; https://git.kernel.org/stable/c/7c4fd5de39f273626a2b0f3a446d2cc85cd47616
CVE: CVE-2021-47385
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

hwmon: (w83792d) Fix NULL pointer dereference by removing unnecessary structure field

If driver read val value sufficient for
(val & 0x08) && (!(val & 0x80)) && ((val & 0x7) == ((val >> 4) & 0x7))
from device then Null pointer dereference occurs.
(It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)
Also lm75[] does not serve a purpose anymore after switching to
devm_i2c_new_dummy_device() in w83791d_detect_subclients().

The patch fixes possible NULL pointer dereference by removing lm75[].

Found by Linux Driver Verification project (linuxtesting.org).

[groeck: Dropped unnecessary continuation lines, fixed multipline alignment]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0f36b88173f028e372668ae040ab1a496834d278; https://git.kernel.org/stable/c/1499bb2c3a87a2efea0065adab2bd66badee61c3; https://git.kernel.org/stable/c/200ced5ba724d8bbf29dfac4ed1e17a39ccaccd1
CVE: CVE-2021-47386
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field

If driver read val value sufficient for
(val & 0x08) && (!(val & 0x80)) && ((val & 0x7) == ((val >> 4) & 0x7))
from device then Null pointer dereference occurs.
(It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)
Also lm75[] does not serve a purpose anymore after switching to
devm_i2c_new_dummy_device() in w83791d_detect_subclients().

The patch fixes possible NULL pointer dereference by removing lm75[].

Found by Linux Driver Verification project (linuxtesting.org).

[groeck: Dropped unnecessary continuation lines, fixed multi-line alignment]
CVSS Score: 7.8 (HIGH)
CWE: CWE-476
References: https://git.kernel.org/stable/c/16887ae4e3defd2c4e7913b6c539f33eaf4eac5c; https://git.kernel.org/stable/c/44d3c480e4e2a75bf6296a18b[PII_REDACTED]ccd80; https://git.kernel.org/stable/c/516d[PII_REDACTED]a20a698103be2b556b4c976bb8
CVE: CVE-2021-47387
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

cpufreq: schedutil: Use kobject release() method to free sugov_tunables

The struct sugov_tunables is protected by the kobject, so we can't free
it directly. Otherwise we would get a call trace like this:
  ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x30
  WARNING: CPU: 3 PID: 720 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100
  Modules linked in:
  CPU: 3 PID: 720 Comm: a.sh Tainted: G        W         5.14.0-rc1-next-20210715-yocto-standard+ #507
  Hardware name: Marvell OcteonTX CN96XX board (DT)
  pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--)
  pc : debug_print_object+0xb8/0x100
  lr : debug_print_object+0xb8/0x100
  sp : ffff80001ecaf910
  x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: ffff800011043d80
  x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: [PII_REDACTED]
  x23: ffff80001142aa68 x22: ffff800011043d80 x21: ffff00010de46f20
  x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: [PII_REDACTED]
  x17: 6e[PII_REDACTED]696c x16: 5f72656d6974203a x15: [PII_REDACTED]
  x14: 6a626f[PII_REDACTED] x13: 303378302f307830 x12: 2b6e665f72656d69
  x11: ffff8000124b1560 x10: ffff[PII_REDACTED]20 x9 : ffff8000100ca6b0
  x8 :[PII_REDACTED]17ffe8 x7 : c0000000fffeffff x6 : [PII_REDACTED]
  x5 : ffff800011d8c000 x4 : ffff800011d8c740 x3 : [PII_REDACTED]
  x2 : ffff[PII_REDACTED]c0 x1 : ab3c90eedf9c0f00 x0 : [PII_REDACTED]
  Call trace:
   debug_print_object+0xb8/0x100
   __debug_check_no_obj_freed+0x1c0/0x230
   debug_check_no_obj_freed+0x20/0x88
   slab_free_freelist_hook+0x154/0x1c8
   kfree+0x114/0x5d0
   sugov_exit+0xbc/0xc0
   cpufreq_exit_governor+0x44/0x90
   cpufreq_set_policy+0x268/0x4a8
   store_scaling_governor+0xe0/0x128
   store+0xc0/0xf0
   sysfs_kf_write+0x54/0x80
   kernfs_fop_write_iter+0x128/0x1c0
   new_sync_write+0xf0/0x190
   vfs_write+0x2d4/0x478
   ksys_write+0x74/0x100
   __arm64_sys_write+0x24/0x30
   invoke_syscall.constprop.0+0x54/0xe0
   do_el0_svc+0x64/0x158
   el0_svc+0x2c/0xb0
   el0t_64_sync_handler+0xb0/0xb8
   el0t_64_sync+0x198/0x19c
  irq event stamp: 5518
  hardirqs last  enabled at (5517): [<ffff8000100cbd7c>] console_unlock+0x554/0x6c8
  hardirqs last disabled at (5518): [<ffff800010fc0638>] el1_dbg+0x28/0xa0
  softirqs last  enabled at (5504): [<ffff[PII_REDACTED]e0>] __do_softirq+0x4d0/0x6c0
  softirqs last disabled at (5483): [<ffff[PII_REDACTED]48>] irq_exit+0x1b0/0x1b8

So split the original sugov_tunables_free() into two functions,
sugov_clear_global_tunables() is just used to clear the global_tunables
and the new sugov_tunables_free() is used as kobj_type::release to
release the sugov_tunables safely.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-763
References: https://git.kernel.org/stable/c/30d57cf2c4116ca6d34ecd1cac94ad84f8bc446c; https://git.kernel.org/stable/c/463c46705f321201090b69c4ad5da0cd2ce614c9; https://git.kernel.org/stable/c/67c98e023135ff81b8d52998a6fdb8ca0c518d82
CVE: CVE-2021-47388
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

mac80211: fix use-after-free in CCMP/GCMP RX

When PN checking is done in mac80211, for fragmentation we need
to copy the PN to the RX struct so we can later use it to do a
comparison, since commit bf30ca922a0c ("mac80211: check defrag
PN against current frame").

Unfortunately, in that commit I used the 'hdr' variable without
it being necessarily valid, so use-after-free could occur if it
was necessary to reallocate (parts of) the frame.

Fix this by reloading the variable after the code that results
in the reallocations, if any.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/27d3eb5616ee2c0a3b30c3fa34813368ed1f3dc9; https://git.kernel.org/stable/c/31de381aef0ab1b342f62485118dc8a19363dc78; https://git.kernel.org/stable/c/3d5d629c99c468458022e9b381789de3595bf4dd
CVE: CVE-2021-47389
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: fix missing sev_decommission in sev_receive_start

DECOMMISSION the current SEV context if binding an ASID fails after
RECEIVE_START.  Per AMD's SEV API, RECEIVE_START generates a new guest
context and thus needs to be paired with DECOMMISSION:

     The RECEIVE_START command is the only command other than the LAUNCH_START
     command that generates a new guest context and guest handle.

The missing DECOMMISSION can result in subsequent SEV launch failures,
as the firmware leaks memory and might not able to allocate more SEV
guest contexts in the future.

Note, LAUNCH_START suffered the same bug, but was previously fixed by
commit 934002cd660b ("KVM: SVM: Call SEV Guest Decommission if ASID
binding fails").
CVSS Score: 5.1 (MEDIUM)
CWE: CWE-772
References: https://git.kernel.org/stable/c/efd7866e114dcb44f86d151e843f8276b7efbc67; https://git.kernel.org/stable/c/f1815e0aa770f2127c5df31eb5c2f0e37b60fa77; https://git.kernel.org/stable/c/efd7866e114dcb44f86d151e843f8276b7efbc67
CVE: CVE-2021-47390
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect()

KASAN reports the following issue:

 BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
 Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798

 CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G               X --------- ---
 Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020
 Call Trace:
  dump_stack+0xa5/0xe6
  print_address_description.constprop.0+0x18/0x130
  ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
  __kasan_report.cold+0x7f/0x114
  ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
  kasan_report+0x38/0x50
  kasan_check_range+0xf5/0x1d0
  kvm_make_vcpus_request_mask+0x174/0x440 [kvm]
  kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm]
  ? kvm_arch_exit+0x110/0x110 [kvm]
  ? sched_clock+0x5/0x10
  ioapic_write_indirect+0x59f/0x9e0 [kvm]
  ? static_obj+0xc0/0xc0
  ? __lock_acquired+0x1d2/0x8c0
  ? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm]

The problem appears to be that 'vcpu_bitmap' is allocated as a single long
on stack and it should really be KVM_MAX_VCPUS long. We also seem to clear
the lower 16 bits of it with bitmap_zero() for no particular reason (my
guess would be that 'bitmap' and 'vcpu_bitmap' variables in
kvm_bitmap_or_dest_vcpus() caused the confusion: while the later is indeed
16-bit long, the later should accommodate all possible vCPUs).
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/2f9b68f57c6278c322793a06063181deded0ad69; https://git.kernel.org/stable/c/99a9e9b80f19fc63be005a33d76211dd23114792; https://git.kernel.org/stable/c/bebabb76ad9acca8858e0371e102fb60d708e25b
CVE: CVE-2021-47391
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests

The FSM can run in a circle allowing rdma_resolve_ip() to be called twice
on the same id_priv. While this cannot happen without going through the
work, it violates the invariant that the same address resolution
background request cannot be active twice.

       CPU 1                                  CPU 2

rdma_resolve_addr():
  RDMA_CM_IDLE -> RDMA_CM_ADDR_QUERY
  rdma_resolve_ip(addr_handler)  #1

			 process_one_req(): for #1
                          addr_handler():
                            RDMA_CM_ADDR_QUERY -> RDMA_CM_ADDR_BOUND
                            mutex_unlock(&id_priv->handler_mutex);
                            [.. handler still running ..]

rdma_resolve_addr():
  RDMA_CM_ADDR_BOUND -> RDMA_CM_ADDR_QUERY
  rdma_resolve_ip(addr_handler)
    !! two requests are now on the req_list

rdma_destroy_id():
 destroy_id_handler_unlock():
  _destroy_id():
   cma_cancel_operation():
    rdma_addr_cancel()

                          // process_one_req() self removes it
		          spin_lock_bh(&lock);
                           cancel_delayed_work(&req->work);
	                   if (!list_empty(&req->list)) == true

      ! rdma_addr_cancel() returns after process_on_req #1 is done

   kfree(id_priv)

			 process_one_req(): for #2
                          addr_handler():
	                    mutex_lock(&id_priv->handler_mutex);
                            !! Use after free on id_priv

rdma_addr_cancel() expects there to be one req on the list and only
cancels the first one. The self-removal behavior of the work only happens
after the handler has returned. This yields a situations where the
req_list can have two reqs for the same "handle" but rdma_addr_cancel()
only cancels the first one.

The second req remains active beyond rdma_destroy_id() and will
use-after-free id_priv once it inevitably triggers.

Fix this by remembering if the id_priv has called rdma_resolve_ip() and
always cancel before calling it again. This ensures the req_list never
gets more than one item in it and doesn't cost anything in the normal flow
that never uses this strange error path.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/03d884671572af8bcfbc9e63944c1021efce7589; https://git.kernel.org/stable/c/305d568b72f17f674155a2a8275f865f207b3808; https://git.kernel.org/stable/c/9a085fa9b7d644a234465091e038c1911e1a4f2a
CVE: CVE-2021-47392
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/cma: Fix listener leak in rdma_cma_listen_on_all() failure

If cma_listen_on_all() fails it leaves the per-device ID still on the
listen_list but the state is not set to RDMA_CM_ADDR_BOUND.

When the cmid is eventually destroyed cma_cancel_listens() is not called
due to the wrong state, however the per-device IDs are still holding the
refcount preventing the ID from being destroyed, thus deadlocking:

 task:rping state:D stack:   0 pid:19605 ppid: 47036 flags:0x00000084
 Call Trace:
  __schedule+0x29a/0x780
  ? free_unref_page_commit+0x9b/0x110
  schedule+0x3c/0xa0
  schedule_timeout+0x215/0x2b0
  ? __flush_work+0x19e/0x1e0
  wait_for_completion+0x8d/0xf0
  _destroy_id+0x144/0x210 [rdma_cm]
  ucma_close_id+0x2b/0x40 [rdma_ucm]
  __destroy_id+0x93/0x2c0 [rdma_ucm]
  ? __xa_erase+0x4a/0xa0
  ucma_destroy_id+0x9a/0x120 [rdma_ucm]
  ucma_write+0xb8/0x130 [rdma_ucm]
  vfs_write+0xb4/0x250
  ksys_write+0xb5/0xd0
  ? syscall_trace_enter.isra.19+0x123/0x190
  do_syscall_64+0x33/0x40
  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Ensure that cma_listen_on_all() atomically unwinds its action under the
lock during error.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3f4e68902d2e545033c80d7ad62fd9a439e573f4; https://git.kernel.org/stable/c/ca465e1f1f9b38fe916a36f7d80c5d25f2337c81; https://git.kernel.org/stable/c/e56a5146ef8cb51cd7c9e748267dce7564448a35
CVE: CVE-2021-47394
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: unlink table before deleting it

syzbot reports following UAF:
BUG: KASAN: use-after-free in memcmp+0x18f/0x1c0 lib/string.c:955
 nla_strcmp+0xf2/0x130 lib/nlattr.c:836
 nft_table_lookup.part.0+0x1a2/0x460 net/netfilter/nf_tables_api.c:570
 nft_table_lookup net/netfilter/nf_tables_api.c:4064 [inline]
 nf_tables_getset+0x1b3/0x860 net/netfilter/nf_tables_api.c:4064
 nfnetlink_rcv_msg+0x659/0x13f0 net/netfilter/nfnetlink.c:285
 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504

Problem is that all get operations are lockless, so the commit_mutex
held by nft_rcv_nl_event() isn't enough to stop a parallel GET request
from doing read-accesses to the table object even after synchronize_rcu().

To avoid this, unlink the table first and store the table objects in
on-stack scratch space.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/a499b03bf36b0c2e3b958a381d828678ab0ffc5e; https://git.kernel.org/stable/c/f65c73d3aabb87d4353e0bc4a718b5ae8c43fd04; https://git.kernel.org/stable/c/a499b03bf36b0c2e3b958a381d828678ab0ffc5e
CVE: CVE-2021-47395
Published: 2024-05-21
Description: In the Linux kernel, the following vulnerability has been resolved:

mac80211: limit injected vht mcs/nss in ieee80211_parse_tx_radiotap

Limit max values for vht mcs and nss in ieee80211_parse_tx_radiotap
routine in order to fix the following warning reported by syzbot:

WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
WARNING: CPU: 0 PID: 10717 at include/net/mac80211.h:989 ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
Modules linked in:
CPU: 0 PID: 10717 Comm: syz-executor.5 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:ieee80211_rate_set_vht include/net/mac80211.h:989 [inline]
RIP: 0010:ieee80211_parse_tx_radiotap+0x101e/0x12d0 net/mac80211/tx.c:2244
RSP: 0018:ffffc9000186f3e8 EFLAGS: 00010216
RAX: [PII_REDACTED] RBX: ffff88804ef76500 RCX: ffffc900143a5000
RDX: [PII_REDACTED] RSI: ffffffff888f478e RDI: [PII_REDACTED]
RBP: 00000000ffffffff R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: ffffffff888f46f9 R11: [PII_REDACTED] R12: 00000000fffffff8
R13: ffff88804ef7653c R14: [PII_REDACTED] R15: [PII_REDACTED]
FS:  00007fbf5718f700(0000) GS:ffff8880b9c00000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 0000001b2de23000 CR3: 000000006a671000 CR4:[PII_REDACTED]1506f0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
Call Trace:
 ieee80211_monitor_select_queue+0xa6/0x250 net/mac80211/iface.c:740
 netdev_core_pick_tx+0x169/0x2e0 net/core/dev.c:4089
 __dev_queue_xmit+0x6f9/0x3710 net/core/dev.c:4165
 __bpf_tx_skb net/core/filter.c:2114 [inline]
 __bpf_redirect_no_mac net/core/filter.c:2139 [inline]
 __bpf_redirect+0x5ba/0xd20 net/core/filter.c:2162
 ____bpf_clone_redirect net/core/filter.c:2429 [inline]
 bpf_clone_redirect+0x2ae/0x420 net/core/filter.c:2401
 bpf_prog_eeb6f53a69e5c6a2+0x59/0x234
 bpf_dispatcher_nop_func include/linux/bpf.h:717 [inline]
 __bpf_prog_run include/linux/filter.h:624 [inline]
 bpf_prog_run include/linux/filter.h:631 [inline]
 bpf_test_run+0x381/0xa30 net/bpf/test_run.c:119
 bpf_prog_test_run_skb+0xb84/0x1ee0 net/bpf/test_run.c:663
 bpf_prog_test_run kernel/bpf/syscall.c:3307 [inline]
 __sys_bpf+0x2137/0x5df0 kernel/bpf/syscall.c:4605
 __do_sys_bpf kernel/bpf/syscall.c:4691 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:4689 [inline]
 __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4689
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x4665f9
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1282bb00835ff79d2d9c023055d514df5b4de260; https://git.kernel.org/stable/c/13cb6d826e0ac0d144b0d48191ff1a111d32f0c6; https://git.kernel.org/stable/c/76538c7b4df314bb937e44c5cb1782f37d47443c