deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-57932
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

gve: guard XDP xmit NDO on existence of xdp queues

In GVE, dedicated XDP queues only exist when an XDP program is installed
and the interface is up. As such, the NDO XDP XMIT callback should
return early if either of these conditions are false.

In the case of no loaded XDP program, priv->num_xdp_queues=0 which can
cause a divide-by-zero error, and in the case of interface down,
num_xdp_queues remains untouched to persist XDP queue count for the next
interface up, but the TX pointer itself would be NULL.

The XDP xmit callback also needs to synchronize with a device
transitioning from open to close. This synchronization will happen via
the GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call,
which waits for any RCU critical sections at call-time to complete.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/35f44eed5828cf1bc7e760d1993ed8549ba41c7b; https://git.kernel.org/stable/c/cbe9eb2c39d09f3c8574febcfa39d8c09d0c7cb5; https://git.kernel.org/stable/c/ff7c2dea9dd1a436fc79d6273adffdcc4a7ffea3
CVE: CVE-2024-57933
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

gve: guard XSK operations on the existence of queues

This patch predicates the enabling and disabling of XSK pools on the
existence of queues. As it stands, if the interface is down, disabling
or enabling XSK pools would result in a crash, as the RX queue pointer
would be NULL. XSK pool registration will occur as part of the next
interface up.

Similarly, xsk_wakeup needs be guarded against queues disappearing
while the function is executing, so a check against the
GVE_PRIV_FLAGS_NAPI_ENABLED flag is added to synchronize with the
disabling of the bit and the synchronize_net() in gve_turndown.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/40338d7987d810fcaa95c500b1068a52b08eec9b; https://git.kernel.org/stable/c/771d66f2bd8c4dba1286a9163ab982cecd825718; https://git.kernel.org/stable/c/8e8d7037c89437af12725f454e2eaf40e8166c0f
CVE: CVE-2024-57934
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

fgraph: Add READ_ONCE() when accessing fgraph_array[]

In __ftrace_return_to_handler(), a loop iterates over the fgraph_array[]
elements, which are fgraph_ops. The loop checks if an element is a
fgraph_stub to prevent using a fgraph_stub afterward.

However, if the compiler reloads fgraph_array[] after this check, it might
race with an update to fgraph_array[] that introduces a fgraph_stub. This
could result in the stub being processed, but the stub contains a null
"func_hash" field, leading to a NULL pointer dereference.

To ensure that the gops compared against the fgraph_stub matches the gops
processed later, add a READ_ONCE(). A similar patch appears in commit
63a8dfb ("function_graph: Add READ_ONCE() when accessing fgraph_array[]").
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/b68b2a3fbacc7be720ef589d489bcacdd05c6d38; https://git.kernel.org/stable/c/d[PII_REDACTED]0ded0a4fe9a097fce72328655b41d
CVE: CVE-2024-57935
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/hns: Fix accessing invalid dip_ctx during destroying QP

If it fails to modify QP to RTR, dip_ctx will not be attached. And
during detroying QP, the invalid dip_ctx pointer will be accessed.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0572eccf239ce4bd89bd531767ec5ab20e249290; https://git.kernel.org/stable/c/a448c775f0aec6cfbee4bda561447c707153504a
CVE: CVE-2024-57936
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/bnxt_re: Fix max SGEs for the Work Request

Gen P7 supports up to 13 SGEs for now. WQE software structure
can hold only 6 now. Since the max send sge is reported as
13, the stack can give requests up to 13 SGEs. This is causing
traffic failures and system crashes.

Use the define for max SGE supported for variable size. This
will work for both static and variable WQEs.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3de1b50f055dc2ca7072a526cdda21f691c22dd9; https://git.kernel.org/stable/c/79d330fbdffd8cee06d8bdf38d82cb62d8363a27; https://git.kernel.org/stable/c/9a479088e0c8f6140b8c7752b563bc8c6c6dcc8c
CVE: CVE-2024-57937
Published: 2025-01-21
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-57938
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net/sctp: Prevent autoclose integer overflow in sctp_association_init()

While by default max_autoclose equals to INT_MAX / HZ, one may set
net.sctp.max_autoclose to UINT_MAX. There is code in
sctp_association_init() that can consequently trigger overflow.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190, CWE-190
References: https://git.kernel.org/stable/c/081bdb3a[PII_REDACTED]3c6d702af922bc29de2c53; https://git.kernel.org/stable/c/2297890b778b0e7c8200d6818154f7e461d78e94; https://git.kernel.org/stable/c/271f031f4c31c07e2a85a1ba2b4c8e734909a477
CVE: CVE-2025-0614
Published: 2025-01-21
Description: Input validation vulnerability in Qualifio's Wheel of Fortune. This vulnerability could allow an attacker to modify a single email to contain upper and lower case characters in order to access the application and win prizes as many times as wanted.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-22
References: https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-qualifios-wheel-fortune
CVE: CVE-2025-0615
Published: 2025-01-21
Description: Input validation vulnerability in Qualifio's Wheel of Fortune. This vulnerability allows an attacker to modify an email to contain the ‘+’ symbol to access the application and win prizes as many times as wanted.
CVSS Score: 5.3 (MEDIUM)
CWE: CWE-22
References: https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-qualifios-wheel-fortune
CVE: CVE-2024-57939
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

riscv: Fix sleeping in invalid context in die()

die() can be called in exception handler, and therefore cannot sleep.
However, die() takes spinlock_t which can sleep with PREEMPT_RT enabled.
That causes the following warning:

BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 285, name: mutex
preempt_count: 110001, expected: 0
RCU nest depth: 0, expected: 0
CPU: 0 UID: 0 PID: 285 Comm: mutex Not tainted 6.12.0-rc7-00022-ge19049cf7d56-dirty #234
Hardware name: riscv-virtio,qemu (DT)
Call Trace:
    dump_backtrace+0x1c/0x24
    show_stack+0x2c/0x38
    dump_stack_lvl+0x5a/0x72
    dump_stack+0x14/0x1c
    __might_resched+0x130/0x13a
    rt_spin_lock+0x2a/0x5c
    die+0x24/0x112
    do_trap_insn_illegal+0xa0/0xea
    _new_vmalloc_restore_context_a0+0xcc/0xd8
Oops - illegal instruction [#1]

Switch to use raw_spinlock_t, which does not sleep even with PREEMPT_RT
enabled.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/10c24df2e303f517fab0359392c11b6b1d553f2b; https://git.kernel.org/stable/c/6a97f4118ac07cfdc316433f385dbdc12af5025e; https://git.kernel.org/stable/c/76ab0afcdbe8c9685b589016ee1c0e25fe596707
CVE: CVE-2024-57940
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

exfat: fix the infinite loop in exfat_readdir()

If the file system is corrupted so that a cluster is linked to
itself in the cluster chain, and there is an unused directory
entry in the cluster, 'dentry' will not be incremented, causing
condition 'dentry < max_dentries' unable to prevent an infinite
loop.

This infinite loop causes s_lock not to be released, and other
tasks will hang, such as exfat_sync_fs().

This commit stops traversing the cluster chain when there is unused
directory entry in the cluster to avoid this infinite loop.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/28c21f0ac5293a4bf19b3e0e32005d6dd31a6c17; https://git.kernel.org/stable/c/31beabd0f47f8c3ed9965ba861c9e5b252d4920a; https://git.kernel.org/stable/c/d8cfbb8723bd3d3222f360227a1cc15227189ca6
CVE: CVE-2024-57941
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled

When the caching for a cookie is temporarily disabled (e.g. due to a DIO
write on that file), future copying to the cache for that file is disabled
until all fds open on that file are closed.  However, if netfslib is using
the deprecated PG_private_2 method (such as is currently used by ceph), and
decides it wants to copy to the cache, netfs_advance_write() will just bail
at the first check seeing that the cache stream is unavailable, and
indicate that it dealt with all the content.

This means that we have no subrequests to provide notifications to drive
the state machine or even to pin the request and the request just gets
discarded, leaving the folios with PG_private_2 set.

Fix this by jumping directly to cancel the request if the cache is not
available.  That way, we don't remove mark3 from the folio_queue list and
netfs_pgpriv2_cancel() will clean up the folios.

This was found by running the generic/013 xfstest against ceph with an
active cache and the "-o fsc" option passed to ceph.  That would usually
hang
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/ba37bdfe59fb43e80dd79290340a21864ba4b61e; https://git.kernel.org/stable/c/d0327c824338cdccad058723a31d038ecd553409
CVE: CVE-2024-57942
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix ceph copy to cache on write-begin

At the end of netfs_unlock_read_folio() in which folios are marked
appropriately for copying to the cache (either with by being marked dirty
and having their private data set or by having PG_private_2 set) and then
unlocked, the folio_queue struct has the entry pointing to the folio
cleared.  This presents a problem for netfs_pgpriv2_write_to_the_cache(),
which is used to write folios marked with PG_private_2 to the cache as it
expects to be able to trawl the folio_queue list thereafter to find the
relevant folios, leading to a hang.

Fix this by not clearing the folio_queue entry if we're going to do the
deprecated copy-to-cache.  The clearance will be done instead as the folios
are written to the cache.

This can be reproduced by starting cachefiles, mounting a ceph filesystem
with "-o fsc" and writing to it.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/38cf8e945721ffe708fa675507465da7f4f2a9f7; https://git.kernel.org/stable/c/43b8d3249b0b71bad239d42dbe08ce6c938ba000
CVE: CVE-2024-57943
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

exfat: fix the new buffer was not zeroed before writing

Before writing, if a buffer_head marked as new, its data must
be zeroed, otherwise uninitialized data in the page cache will
be written.

So this commit uses folio_zero_new_buffers() to zero the new
buffers before ->write_end().
CVSS Score: 7.8 (HIGH)
CWE: CWE-824, CWE-824
References: https://git.kernel.org/stable/c/942c6f91ab8d82a41650e717940b4e577173762f; https://git.kernel.org/stable/c/98e2fb26d1a9eafe79f46d15d54e68e014d81d8c
CVE: CVE-2024-57944
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: adc: ti-ads1298: Add NULL check in ads1298_init

devm_kasprintf() can return a NULL pointer on failure. A check on the
return value of such a call in ads1298_init() is missing. Add it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/69b680bbac9bd611aaa308769d6c71e3e70eb3c3; https://git.kernel.org/stable/c/bcb394bb28e55312cace75362b8e489eb0e02a30
CVE: CVE-2024-57945
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

riscv: mm: Fix the out of bound issue of vmemmap address

In sparse vmemmap model, the virtual address of vmemmap is calculated as:
((struct page *)VMEMMAP_START - (phys_ram_base >> PAGE_SHIFT)).
And the struct page's va can be calculated with an offset:
(vmemmap + (pfn)).

However, when initializing struct pages, kernel actually starts from the
first page from the same section that phys_ram_base belongs to. If the
first page's physical address is not (phys_ram_base >> PAGE_SHIFT), then
we get an va below VMEMMAP_START when calculating va for it's struct page.

For example, if phys_ram_base starts from 0x82000000 with pfn 0x82000, the
first page in the same section is actually pfn 0x80000. During
init_unavailable_range(), we will initialize struct page for pfn 0x80000
with virtual address ((struct page *)VMEMMAP_START - 0x2000), which is
below VMEMMAP_START as well as PCI_IO_END.

This commit fixes this bug by introducing a new variable
'vmemmap_start_pfn' which is aligned with memory section size and using
it to calculate vmemmap address instead of phys_ram_base.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/92f08673d3f[PII_REDACTED]72f60e3c62f2e57c2f; https://git.kernel.org/stable/c/a4a7ac3d266008018f05fae53060fcb331151a14; https://git.kernel.org/stable/c/d2bd51954ac8377c2f1eb1813e694788998add66
CVE: CVE-2024-57946
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio-blk: don't keep queue frozen during system suspend

Commit 4ce6e2db00de ("virtio-blk: Ensure no requests in virtqueues before
deleting vqs.") replaces queue quiesce with queue freeze in virtio-blk's
PM callbacks. And the motivation is to drain inflight IOs before suspending.

block layer's queue freeze looks very handy, but it is also easy to cause
deadlock, such as, any attempt to call into bio_queue_enter() may run into
deadlock if the queue is frozen in current context. There are all kinds
of ->suspend() called in suspend context, so keeping queue frozen in the
whole suspend context isn't one good idea. And Marek reported lockdep
warning[1] caused by virtio-blk's freeze queue in virtblk_freeze().

[1] https://lore.kernel.org/linux-block/ca16370e-d646-4eee-b9cc-87277c89c43c@samsung.com/

Given the motivation is to drain in-flight IOs, it can be done by calling
freeze & unfreeze, meantime restore to previous behavior by keeping queue
quiesced during suspend.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667, CWE-667
References: https://git.kernel.org/stable/c/12c0ddd6c551c1e438b087f874b4f1223a75f7ea; https://git.kernel.org/stable/c/6dea8e3de59928974bf157dd0499d3958d744ae4; https://git.kernel.org/stable/c/7678abee0867e6b7fb89aa40f6e9f575f755fb37
CVE: CVE-2025-21656
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

hwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occur

scsi_execute_cmd() function can return both negative (linux codes) and
positive (scsi_cmnd result field) error codes.

Currently the driver just passes error codes of scsi_execute_cmd() to
hwmon core, which is incorrect because hwmon only checks for negative
error codes. This leads to hwmon reporting uninitialized data to
userspace in case of SCSI errors (for example if the disk drive was
disconnected).

This patch checks scsi_execute_cmd() output and returns -EIO if it's
error code is positive.

[groeck: Avoid inline variable declaration for portability]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/42268d885e44af875a6474f7bba519cc6cea6a9d; https://git.kernel.org/stable/c/53e25b10a28edaf8c2a1d3916fd8929501a50dfc; https://git.kernel.org/stable/c/82163d63ae7a4c36142cd[PII_REDACTED]05bb7e4b9
CVE: CVE-2025-21657
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

sched_ext: Replace rq_lock() to raw_spin_rq_lock() in scx_ops_bypass()

scx_ops_bypass() iterates all CPUs to re-enqueue all the scx tasks.
For each CPU, it acquires a lock using rq_lock() regardless of whether
a CPU is offline or the CPU is currently running a task in a higher
scheduler class (e.g., deadline). The rq_lock() is supposed to be used
for online CPUs, and the use of rq_lock() may trigger an unnecessary
warning in rq_pin_lock(). Therefore, replace rq_lock() to
raw_spin_rq_lock() in scx_ops_bypass().

Without this change, we observe the following warning:

===== START =====
[    6.615205] rq->balance_callback && rq->balance_callback != &balance_push_callback
[    6.615208] WARNING: CPU: 2 PID: 0 at kernel/sched/sched.h:1730 __schedule+0x1130/0x1c90
=====  END  =====
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/6268d5bc10354fc2ab8d44a0cd3b042d49a0417e; https://git.kernel.org/stable/c/d9e446dd63cee7161717a6a8414ba9c6435af764
CVE: CVE-2025-21658
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: avoid NULL pointer dereference if no valid extent tree

[BUG]
Syzbot reported a crash with the following call trace:

  BTRFS info (device loop0): scrub: started on devid 1
  BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0
  Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
  CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G           O       6.13.0-rc4-custom+ #206
  Tainted: [O]=OOT_MODULE
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022
  RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs]
  Call Trace:
   <TASK>
   scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs]
   scrub_simple_mirror+0x175/0x260 [btrfs]
   scrub_stripe+0x5d4/0x6c0 [btrfs]
   scrub_chunk+0xbb/0x170 [btrfs]
   scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs]
   btrfs_scrub_dev+0x240/0x600 [btrfs]
   btrfs_ioctl+0x1dc8/0x2fa0 [btrfs]
   ? do_sys_openat2+0xa5/0xf0
   __x64_sys_ioctl+0x97/0xc0
   do_syscall_64+0x4f/0x120
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
   </TASK>

[CAUSE]
The reproducer is using a corrupted image where extent tree root is
corrupted, thus forcing to use "rescue=all,ro" mount option to mount the
image.

Then it triggered a scrub, but since scrub relies on extent tree to find
where the data/metadata extents are, scrub_find_fill_first_stripe()
relies on an non-empty extent root.

But unfortunately scrub_find_fill_first_stripe() doesn't really expect
an NULL pointer for extent root, it use extent_root to grab fs_info and
triggered a NULL pointer dereference.

[FIX]
Add an extra check for a valid extent root at the beginning of
scrub_find_fill_first_stripe().

The new error path is introduced by 42437a6386ff ("btrfs: introduce
mount option rescue=ignorebadroots"), but that's pretty old, and later
commit b979547513ff ("btrfs: scrub: introduce helper to find and fill
sector info for a scrub_stripe") changed how we do scrub.

So for kernels older than 6.6, the fix will need manual backport.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/24b85a8b0310e0144da9ab30be42e87e6476638a; https://git.kernel.org/stable/c/6aecd91a5c5b68939cf4169e32bc49f3cd2dd329; https://git.kernel.org/stable/c/aee5f69f3e6cd82bfefaca1b70b40b6cd8f3f784
CVE: CVE-2025-21659
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

netdev: prevent accessing NAPI instances from another namespace

The NAPI IDs were not fully exposed to user space prior to the netlink
API, so they were never namespaced. The netlink API must ensure that
at the very least NAPI instance belongs to the same netns as the owner
of the genl sock.

napi_by_id() can become static now, but it needs to move because of
dev_get_by_napi_id().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/b683ba0df11ff563cc237eb1b74d6adfa77226bf; https://git.kernel.org/stable/c/d1cacd74776895f6435941f86a1130e58f6dd226
CVE: CVE-2025-21660
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix unexpectedly changed path in ksmbd_vfs_kern_path_locked

When `ksmbd_vfs_kern_path_locked` met an error and it is not the last
entry, it will exit without restoring changed path buffer. But later this
buffer may be used as the filename for creation.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/13e41c58c74baa71f34c0830eaa3c29d53a6e964; https://git.kernel.org/stable/c/2ac538e40278a2c0c051cca81bcaafc547d61372; https://git.kernel.org/stable/c/51669f4af5f7959565b48e55691ba92fabf5c587
CVE: CVE-2025-21661
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

gpio: virtuser: fix missing lookup table cleanups

When a virtuser device is created via configfs and the probe fails due
to an incorrect lookup table, the table is not removed. This prevents
subsequent probe attempts from succeeding, even if the issue is
corrected, unless the device is released. Additionally, cleanup is also
needed in the less likely case of platform_device_register_full()
failure.

Besides, a consistent memory leak in lookup_table->dev_id was spotted
using kmemleak by toggling the live state between 0 and 1 with a correct
lookup table.

Introduce gpio_virtuser_remove_lookup_table() as the counterpart to the
existing gpio_virtuser_make_lookup_table() and call it from all
necessary points to ensure proper cleanup.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/a619cba8c69c434258ff4101d463322cd63e1bdc; https://git.kernel.org/stable/c/d72d0126b1f6981f6ce8b4247305f359958c11b5
CVE: CVE-2025-21662
Published: 2025-01-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Fix variable not being completed when function returns

When cmd_alloc_index(), fails cmd_work_handler() needs
to complete ent->slotted before returning early.
Otherwise the task which issued the command may hang:

   mlx5_core 0000:01:00.0: cmd_work_handler:877:(pid 3880418): failed to allocate command entry
   INFO: task kworker/13:2:4055883 blocked for more than 120 seconds.
         Not tainted 4.19.90-25.44.v2101.ky10.aarch64 #1
   "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
   kworker/13:2    D    0 4055883      2 0x00000228
   Workqueue: events mlx5e_tx_dim_work [mlx5_core]
   Call trace:
      __switch_to+0xe8/0x150
      __schedule+0x2a8/0x9b8
      schedule+0x2c/0x88
      schedule_timeout+0x204/0x478
      wait_for_common+0x154/0x250
      wait_for_completion+0x28/0x38
      cmd_exec+0x7a0/0xa00 [mlx5_core]
      mlx5_cmd_exec+0x54/0x80 [mlx5_core]
      mlx5_core_modify_cq+0x6c/0x80 [mlx5_core]
      mlx5_core_modify_cq_moderation+0xa0/0xb8 [mlx5_core]
      mlx5e_tx_dim_work+0x54/0x68 [mlx5_core]
      process_one_work+0x1b0/0x448
      worker_thread+0x54/0x468
      kthread+0x134/0x138
      ret_from_fork+0x10/0x18
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0e2909c6bec9048f49d0c8e16887c63b50b14647; https://git.kernel.org/stable/c/229cc10284373fbe754e623b7033dca7e7470ec8; https://git.kernel.org/stable/c/36124081f6ffd9dfaad48830bdf106bb82a9457d