deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-2253
Published: 2025-05-09
Description: The IMITHEMES Listing plugin is vulnerable to privilege escalation via account takeover in all versions up to, and including, 3.3. This is due to the plugin not properly validating a verification code value prior to updating their password through the imic_reset_password_init() function. This makes it possible for unauthenticated attackers to change any user's passwords, including administrators if the users email is known.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-620
References: https://themeforest.net/item/auto-stars-car-dealership-listings-wp-theme/11560490; https://www.wordfence.com/threat-intel/vulnerabilities/id/4ed0ea4a-9cbf-4033-a31f-6cb954e8ce01?source=cve
CVE: CVE-2025-37835
Published: 2025-05-09
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-37836
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: Fix reference leak in pci_register_host_bridge()

If device_register() fails, call put_device() to give up the reference to
avoid a memory leak, per the comment at device_register().

Found by code review.

[bhelgaas: squash Dan Carpenter's double free fix from
https://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3297497ad2246eb9243849bfbbc57a0dea97d76e; https://git.kernel.org/stable/c/804443c1f27883926de94c849d91f5b7d7d696e9; https://git.kernel.org/stable/c/9707d0c932f41006a2701afc926b232b50e356b4
CVE: CVE-2025-37837
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/tegra241-cmdqv: Fix warnings due to dmam_free_coherent()

Two WARNINGs are observed when SMMU driver rolls back upon failure:
 arm-smmu-v3.9.auto: Failed to register iommu
 arm-smmu-v3.9.auto: probe with driver arm-smmu-v3 failed with error -22
 ------------[ cut here ]------------
 WARNING: CPU: 5 PID: 1 at kernel/dma/mapping.c:74 dmam_free_coherent+0xc0/0xd8
 Call trace:
  dmam_free_coherent+0xc0/0xd8 (P)
  tegra241_vintf_free_lvcmdq+0x74/0x188
  tegra241_cmdqv_remove_vintf+0x60/0x148
  tegra241_cmdqv_remove+0x48/0xc8
  arm_smmu_impl_remove+0x28/0x60
  devm_action_release+0x1c/0x40
 ------------[ cut here ]------------
 128 pages are still in use!
 WARNING: CPU: 16 PID: 1 at mm/page_alloc.c:6902 free_contig_range+0x18c/0x1c8
 Call trace:
  free_contig_range+0x18c/0x1c8 (P)
  cma_release+0x154/0x2f0
  dma_free_contiguous+0x38/0xa0
  dma_direct_free+0x10c/0x248
  dma_free_attrs+0x100/0x290
  dmam_free_coherent+0x78/0xd8
  tegra241_vintf_free_lvcmdq+0x74/0x160
  tegra241_cmdqv_remove+0x98/0x198
  arm_smmu_impl_remove+0x28/0x60
  devm_action_release+0x1c/0x40

This is because the LVCMDQ queue memory are managed by devres, while that
dmam_free_coherent() is called in the context of devm_action_release().

Jason pointed out that "arm_smmu_impl_probe() has mis-ordered the devres
callbacks if ops->device_remove() is going to be manually freeing things
that probe allocated":
https://lore.kernel.org/linux-iommu/[PII_REDACTED]4408.GB1722458@nvidia.com/

In fact, tegra241_cmdqv_init_structures() only allocates memory resources
which means any failure that it generates would be similar to -ENOMEM, so
there is no point in having that "falling back to standard SMMU" routine,
as the standard SMMU would likely fail to allocate memory too.

Remove the unwind part in tegra241_cmdqv_init_structures(), and return a
proper error code to ask SMMU driver to call tegra241_cmdqv_remove() via
impl_ops->device_remove(). Then, drop tegra241_vintf_free_lvcmdq() since
devres will take care of that.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5584dbf393df[PII_REDACTED]45a487b1ef76557722; https://git.kernel.org/stable/c/767e22001dfce64cc03b7def[PII_REDACTED]ab6031; https://git.kernel.org/stable/c/e38ed[PII_REDACTED]d8fa1763d1da86b584f9eb55b
CVE: CVE-2025-37839
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

jbd2: remove wrong sb->s_sequence check

Journal emptiness is not determined by sb->s_sequence == 0 but rather by
sb->s_start == 0 (which is set a few lines above). Furthermore 0 is a
valid transaction ID so the check can spuriously trigger. Remove the
invalid WARN_ON.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/3b4643ffaf72d7a5a357e9bf68b1775f8cfe7e77; https://git.kernel.org/stable/c/9eaec071f111cd2124ce9a5b93536d3f6837d457; https://git.kernel.org/stable/c/ad926f735b4d4f10768fec7d080cadeb6d075cac
CVE: CVE-2025-37841
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

pm: cpupower: bench: Prevent NULL dereference on malloc failure

If malloc returns NULL due to low memory, 'config' pointer can be NULL.
Add a check to prevent NULL dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0e297a02e03dceb2874789ca40bd4e65c5371704; https://git.kernel.org/stable/c/208baa3ec9043a664d9acfb8174b332e6b17fb69; https://git.kernel.org/stable/c/34a9394794b0f97af6afedc0c9ee2012c24b28ed
CVE: CVE-2025-37842
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

spi: fsl-qspi: use devm function instead of driver remove

Driver use devm APIs to manage clk/irq/resources and register the spi
controller, but the legacy remove function will be called first during
device detach and trigger kernel panic. Drop the remove function and use
devm_add_action_or_reset() for driver cleanup to ensure the release
sequence.

Trigger kernel panic on i.MX8MQ by
echo 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/40369bfe717e96e26650eeecfa5a6363563df6e4; https://git.kernel.org/stable/c/439688dbe82baa10d4430dc3252bb5ef1183a171; https://git.kernel.org/stable/c/50ae352c1848cab408fb4f7d7f50c71f818bbdbf
CVE: CVE-2025-37843
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: pciehp: Avoid unnecessary device replacement check

Hot-removal of nested PCI hotplug ports suffers from a long-standing race
condition which can lead to a deadlock:  A parent hotplug port acquires
pci_lock_rescan_remove(), then waits for pciehp to unbind from a child
hotplug port.  Meanwhile that child hotplug port tries to acquire
pci_lock_rescan_remove() as well in order to remove its own children.

The deadlock only occurs if the parent acquires pci_lock_rescan_remove()
first, not if the child happens to acquire it first.

Several workarounds to avoid the issue have been proposed and discarded
over the years, e.g.:

https://lore.kernel.org/r/4c882e25194ba8282b78fe963fec8faae7cf23eb[PII_REDACTED].git.lukas@wunner.de/

A proper fix is being worked on, but needs more time as it is nontrivial
and necessarily intrusive.

Recent commit 9d573d19547b ("PCI: pciehp: Detect device replacement during
system sleep") provokes more frequent occurrence of the deadlock when
removing more than one Thunderbolt device during system sleep.  The commit
sought to detect device replacement, but also triggered on device removal.
Differentiating reliably between replacement and removal is impossible
because pci_get_dsn() returns 0 both if the device was removed, as well as
if it was replaced with one lacking a Device Serial Number.

Avoid the more frequent occurrence of the deadlock by checking whether the
hotplug port itself was hot-removed.  If so, there's no sense in checking
whether its child device was replaced.

This works because the ->resume_noirq() callback is invoked in top-down
order for the entire hierarchy:  A parent hotplug port detecting device
replacement (or removal) marks all children as removed using
pci_dev_set_disconnected() and a child hotplug port can then reliably
detect being removed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0d0bbd01f7c0ac7d1be9f85aaf2cd0baec34655f; https://git.kernel.org/stable/c/7535d10a2c61baeff493300070cf04d9ddda216b; https://git.kernel.org/stable/c/e3260237aaadc9799107ccb940c6688195c4518d
CVE: CVE-2025-37844
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

cifs: avoid NULL pointer dereference in dbg call

cifs_server_dbg() implies server to be non-NULL so
move call under condition to avoid NULL pointer dereference.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/20048e658652e731f5cadf4a695925e570ca0ff9; https://git.kernel.org/stable/c/6c14ee6af8f1f188b668afd6d003f7516a507b08; https://git.kernel.org/stable/c/864ba5c651b03830f36f0906c21af05b15c1aaa6
CVE: CVE-2025-37845
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing: fprobe events: Fix possible UAF on modules

Commit ac91052f0ae5 ("tracing: tprobe-events: Fix leakage of module
refcount") moved try_module_get() from __find_tracepoint_module_cb()
to find_tracepoint() caller, but that introduced a possible UAF
because the module can be unloaded before try_module_get(). In this
case, the module object should be freed too. Thus, try_module_get()
does not only fail but may access to the freed object.

To avoid that, try_module_get() in __find_tracepoint_module_cb()
again.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/626f01f4d26e8cf92e69c1df53036153c8e98a20; https://git.kernel.org/stable/c/868df4eb784c3ccc7e4340a9ea993cbbedca167e; https://git.kernel.org/stable/c/a27d2de2472b1cc7d582ab405d1d5832a80481de
CVE: CVE-2025-37846
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64: mops: Do not dereference src reg for a set operation

The source register is not used for SET* and reading it can result in
a UBSAN out-of-bounds array access error, specifically when the MOPS
exception is taken from a SET* sequence with XZR (reg 31) as the
source. Architecturally this is the only case where a src/dst/size
field in the ESR can be reported as 31.

Prior to 2de451a329cf662b the code in do_el0_mops() was benign as the
use of pt_regs_read_reg() prevented the out-of-bounds access.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/43267d934eacff6c70e15545d804ebbcab8a0bf5; https://git.kernel.org/stable/c/5f6022a[PII_REDACTED]4b781fdc056b291850e7786; https://git.kernel.org/stable/c/a13bfa4fe0d6949cea14718df2d1fe84c38cd113
CVE: CVE-2025-37847
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

accel/ivpu: Fix deadlock in ivpu_ms_cleanup()

Fix deadlock in ivpu_ms_cleanup() by preventing runtime resume after
file_priv->ms_lock is acquired.

During a failure in runtime resume, a cold boot is executed, which
calls ivpu_ms_cleanup_all(). This function calls ivpu_ms_cleanup()
that acquires file_priv->ms_lock and causes the deadlock.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/019634f27a16796eab749e8107dae32099945f29; https://git.kernel.org/stable/c/7d12a7d43c7bab9097ba466581d8db702e7908dc; https://git.kernel.org/stable/c/9a6f56762d23a1f3af15e67901493c927caaf882
CVE: CVE-2025-37848
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

accel/ivpu: Fix PM related deadlocks in MS IOCTLs

Prevent runtime resume/suspend while MS IOCTLs are in progress.
Failed suspend will call ivpu_ms_cleanup() that would try to acquire
file_priv->ms_lock, which is already held by the IOCTLs.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/[PII_REDACTED]6441b45c3c241419dececf20c30104; https://git.kernel.org/stable/c/afada73000bef7c79a22f0d7e93fac414eeff19e; https://git.kernel.org/stable/c/c3d9fc2f2746b52e9f820a13c53b4418bec04b48
CVE: CVE-2025-37849
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Tear down vGIC on failed vCPU creation

If kvm_arch_vcpu_create() fails to share the vCPU page with the
hypervisor, we propagate the error back to the ioctl but leave the
vGIC vCPU data initialised. Note only does this leak the corresponding
memory when the vCPU is destroyed but it can also lead to use-after-free
if the redistributor device handling tries to walk into the vCPU.

Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the
vGIC vCPU structures are destroyed on error.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/07476e0d932afc53c[PII_REDACTED]3ac35d0b4999e; https://git.kernel.org/stable/c/2480326eba8ae9ccc5e4c3c2dc8d407db68e3c52; https://git.kernel.org/stable/c/250f25367b58d8c65a1b060a2dda037eea09a672
CVE: CVE-2025-37850
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()

With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has a
divide-by-zero in the following line:

	do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));

due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()
returns zero.

This is presumably just a theoretical problem: COMPILE_TEST overrides
the dependency on RALINK which would select COMMON_CLK.  Regardless it's
a good idea to check for the error explicitly to avoid divide-by-zero.

Fixes the following warning:

  drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section

[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/4cb15042b5f3ec0474e91cf379120cc597625dbb; https://git.kernel.org/stable/c/77fb96dbe350e8a5ae4965ff9f6e7049f3966a6b; https://git.kernel.org/stable/c/7ca59947b5fcf94e7ea4029d1bd0f7c41500a161
CVE: CVE-2025-37851
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: omapfb: Add 'plane' value check

Function dispc_ovl_setup is not intended to work with the value OMAP_DSS_WB
of the enum parameter plane.

The value of this parameter is initialized in dss_init_overlays and in the
current state of the code it cannot take this value so it's not a real
problem.

For the purposes of defensive coding it wouldn't be superfluous to check
the parameter value, because some functions down the call stack process
this value correctly and some not.

For example, in dispc_ovl_setup_global_alpha it may lead to buffer
overflow.

Add check for this value.

Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-674
References: https://git.kernel.org/stable/c/09dbf22fd68c2f1a81ab89670ffa1ec3033436c4; https://git.kernel.org/stable/c/3e411827f31db7f938a30a3c7a[PII_REDACTED]ec30; https://git.kernel.org/stable/c/4efd8ef5e40f2c7a4a91a5a9f03140bfa827da89
CVE: CVE-2025-37852
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create()

Add error handling to propagate amdgpu_cgs_create_device() failures
to the caller. When amdgpu_cgs_create_device() fails, release hwmgr
and return -ENOMEM to prevent null pointer dereference.

[v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1435e895d4fc967d64e9f5bf81e992ac32f5ac76; https://git.kernel.org/stable/c/22ea19cc089013b55c240134dbb2797700ff5a6a; https://git.kernel.org/stable/c/55ef52c30c3e747f145a64de96192e37a8fed670
CVE: CVE-2025-37853
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: debugfs hang_hws skip GPU with MES

debugfs hang_hws is used by GPU reset test with HWS, for MES this crash
the kernel with NULL pointer access because dqm->packet_mgr is not setup
for MES path.

Skip GPU with MES for now, MES hang_hws debugfs interface will be
supported later.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1a322b330dc0b775d1d7a84e55c752d9451bfe7d; https://git.kernel.org/stable/c/24b9e0e2e6147314c22d821f0542c4dd9a320c40; https://git.kernel.org/stable/c/a36f8d544522a19ef06ed9e84667d154dcb6be52
CVE: CVE-2025-37854
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix mode1 reset crash issue

If HW scheduler hangs and mode1 reset is used to recover GPU, KFD signal
user space to abort the processes. After process abort exit, user queues
still use the GPU to access system memory before h/w is reset while KFD
cleanup worker free system memory and free VRAM.

There is use-after-free race bug that KFD allocate and reuse the freed
system memory, and user queue write to the same system memory to corrupt
the data structure and cause driver crash.

To fix this race, KFD cleanup worker terminate user queues, then flush
reset_domain wq to wait for any GPU ongoing reset complete, and then
free outstanding BOs.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/57c9dabda80ac167de8cd71231baae37cc2f442d; https://git.kernel.org/stable/c/6f30a847432cae84c7428e9b684b3e3fa49b2391; https://git.kernel.org/stable/c/89af6b39f028c130d4362f57042927f005423e6a
CVE: CVE-2025-37855
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Guard Possible Null Pointer Dereference

[WHY]
In some situations, dc->res_pool may be null.

[HOW]
Check if pointer is null before dereference.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/c87d202692de34ee71d1fd4679a549a29095658a; https://git.kernel.org/stable/c/dc2de1ac7145f882f3c03d2d6f84583ae7e35d41
CVE: CVE-2025-37856
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: harden block_group::bg_list against list_del() races

As far as I can tell, these calls of list_del_init() on bg_list cannot
run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),
as they are in transaction error paths and situations where the block
group is readonly.

However, if there is any chance at all of racing with mark_bg_unused(),
or a different future user of bg_list, better to be safe than sorry.

Otherwise we risk the following interleaving (bg_list refcount in parens)

T1 (some random op)                       T2 (btrfs_mark_bg_unused)
                                        !list_empty(&bg->bg_list); (1)
list_del_init(&bg->bg_list); (1)
                                        list_move_tail (1)
btrfs_put_block_group (0)
                                        btrfs_delete_unused_bgs
                                             bg = list_first_entry
                                             list_del_init(&bg->bg_list);
                                             btrfs_put_block_group(bg); (-1)

Ultimately, this results in a broken ref count that hits zero one deref
early and the real final deref underflows the refcount, resulting in a WARNING.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/185fd73e5ac06027c4be9a129e59193f6a3ef202; https://git.kernel.org/stable/c/7511e29cf1355b2c47d0effb39e463119913e2f6; https://git.kernel.org/stable/c/909e60fb469d4101c6b08cf6e622efb062bb24a1
CVE: CVE-2025-37857
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: st: Fix array overflow in st_setup()

Change the array size to follow parms size instead of a fixed value.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/574b399a7fb6ae71c97e26d122205c4a720c0e43; https://git.kernel.org/stable/c/736ae988bfb5932c05625baff70fba224d547c08; https://git.kernel.org/stable/c/7fe3b4deed8b93609058c37c9a11df1d2b2c0423
CVE: CVE-2025-37858
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/jfs: Prevent integer overflow in AG size calculation

The JFS filesystem calculates allocation group (AG) size using 1 <<
l2agsize in dbExtendFS(). When l2agsize exceeds 31 (possible with >2TB
aggregates on 32-bit systems), this 32-bit shift operation causes undefined
behavior and improper AG sizing.

On 32-bit architectures:
- Left-shifting 1 by 32+ bits results in 0 due to integer overflow
- This creates invalid AG sizes (0 or garbage values) in
sbi->bmap->db_agsize
- Subsequent block allocations would reference invalid AG structures
- Could lead to:
  - Filesystem corruption during extend operations
  - Kernel crashes due to invalid memory accesses
  - Security vulnerabilities via malformed on-disk structures

Fix by casting to s64 before shifting:
bmp->db_agsize = (s64)1 << l2agsize;

This ensures 64-bit arithmetic even on 32-bit architectures. The cast
matches the data type of db_agsize (s64) and follows similar patterns in
JFS block calculation code.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/211ed8f5e39e61f9e4d18edd64ce8005a67a1b2a; https://git.kernel.org/stable/c/3d8a45f87010a802aa214bf39702ca9d99cbf3ba; https://git.kernel.org/stable/c/55edbf5dbf60a8195c21e92124c4028939ae16b2
CVE: CVE-2025-37859
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

page_pool: avoid infinite loop to schedule delayed worker

We noticed the kworker in page_pool_release_retry() was waken
up repeatedly and infinitely in production because of the
buggy driver causing the inflight less than 0 and warning
us in page_pool_inflight()[1].

Since the inflight value goes negative, it means we should
not expect the whole page_pool to get back to work normally.

This patch mitigates the adverse effect by not rescheduling
the kworker when detecting the inflight negative in
page_pool_release_retry().

[1]
[Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------
[Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages
...
[Mon Feb 10 20:36:11 2025] Call Trace:
[Mon Feb 10 20:36:11 2025]  page_pool_release_retry+0x23/0x70
[Mon Feb 10 20:36:11 2025]  process_one_work+0x1b1/0x370
[Mon Feb 10 20:36:11 2025]  worker_thread+0x37/0x3a0
[Mon Feb 10 20:36:11 2025]  kthread+0x11a/0x140
[Mon Feb 10 20:36:11 2025]  ? process_one_work+0x370/0x370
[Mon Feb 10 20:36:11 2025]  ? __kthread_cancel_work+0x40/0x40
[Mon Feb 10 20:36:11 2025]  ret_from_fork+0x35/0x40
[Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---
Note: before this patch, the above calltrace would flood the
dmesg due to repeated reschedule of release_dw kworker.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/43130d02baa137033c25297aaae95fd0edc41654; https://git.kernel.org/stable/c/7204335d1991c23fc615ab76f31f175748a578e1; https://git.kernel.org/stable/c/738d1812ec2e395e953258aea912ddd867d11a13
CVE: CVE-2025-37861
Published: 2025-05-09
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue

When the task management thread processes reply queues while the reset
thread resets them, the task management thread accesses an invalid queue ID
(0xFFFF), set by the reset thread, which points to unallocated memory,
causing a crash.

Add flag 'io_admin_reset_sync' to synchronize access between the reset,
I/O, and admin threads. Before a reset, the reset handler sets this flag to
block I/O and admin processing threads. If any thread bypasses the initial
check, the reset thread waits up to 10 seconds for processing to finish. If
the wait exceeds 10 seconds, the controller is marked as unrecoverable.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/65ba18c84dbd03afe9b38c06c151239d97a09834; https://git.kernel.org/stable/c/75b67dca4195e11ccf966a704787b2aa2754a457; https://git.kernel.org/stable/c/8d310d66e2b0f5f9f[PII_REDACTED]47e8a3a4924fa