huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
wifi: mwifiex: Initialize the chan_stats array to zero
CVE: CVE-2025-39891
Component: kernel
CWE: CWE-200
Severity: Moderate
CVSS v3: 6.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Release date: 2025-10-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: mwifiex: Initialize the chan_stats array to zero

The adapter->chan_stats[] array is initialized in
mwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out
memory.  The array is filled in mwifiex_update_chan_statistics()
and then the user can query the data in mwifiex_cfg80211_dump_survey().

There are two potential issues here.  What if the user calls
mwifiex_cfg80211_dump_survey() before the data has been filled in.
Also the mwifiex_update_chan_statistics() function doesn't necessarily
initialize the whole array.  Since the array was not initialized at
the start that could result in an information leak.

Also this array is pretty small.  It's a maximum of 900 bytes so it's
more appropriate to use kcalloc() instead vmalloc().

Statement: The patch fixes an information leak in the Marvell mwifiex driver by zero-initializing the chan_stats array using kcalloc().
Previously, vmalloc() left memory uninitialized, allowing users to read residual kernel data via mwifiex_cfg80211_dump_survey() before full initialization.
Impact is confidentiality only (kernel memory exposure); no integrity or availability risk.
For the CVSS the PR:L — requires local privileges to trigger survey requests, and in typical systems, only network admins can access this interface.

Remediation:
ALSA: usb: scarlett2: Fix missing NULL check
CVE: CVE-2025-38629
Component: kernel
CWE: CWE-476
Severity: Moderate
CVSS v3: 4.7/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-08-22T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb: scarlett2: Fix missing NULL check

scarlett2_input_select_ctl_info() sets up the string arrays allocated
via kasprintf(), but it misses NULL checks, which may lead to NULL
dereference Oops.  Let's add the proper NULL check.


Remediation:
RabbitMQ has XSS Vulnerability in an Error Message in Management UI
CVE: CVE-2025-30219
Component: rabbitmq
CWE: CWE-79
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:L
Release date: 2025-03-25T22:55:35.539000+00:00

A flaw was found in the RabbitMQ package. Affected versions of RabbitMQ are vulnerable to an attack that can modify the virtual host name on the disk and then make it unrecoverable, with other on disk file modifications. This issue can lead to arbitrary JavaScript code execution in the browsers of management UI users. When a virtual host on a RabbitMQ node fails to start, recent versions will display an error message notification in the management UI, including the virtual host name, which was not escaped prior to open source RabbitMQ and Tanzu RabbitMQ. This attack makes a virtual host fail to start and creates a new virtual host name with a XSS code snippet or changes the name of an existing virtual host on disk.


Remediation:
To mitigate this vulnerability, it is recommended to disable the management plugin and use Prometheus and Grafana for monitoring.
MediaWiki: Information disclosure via user interaction in EnhancedChangesList.Php
CVE: CVE-2025-61646
Component: MediaWiki
CVSS v3: 3.7/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N
Release date: 2025-01-01T00:00:00+00:00

A flaw was found in MediaWiki. A low-privileged remote attacker could exploit this vulnerability by tricking a user into interacting with the EnhancedChangesList.Php program file. This could lead to low confidentiality impact, potentially disclosing sensitive information.

Statement: Red Hat Product Security has determined that this vulnerability does not affect any currently supported Red Hat product. This assessment may evolve based on further analysis and discovery. For more information about this vulnerability and the products it affects, please see the linked references.

Remediation:
Drupal core information disclosure
CVE: CVE-2025-13083
Component: drupal
CVSS v3: 3.6/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
Release date: 2025-11-18T16:55:37.269000+00:00

Use of Web Browser Cache Containing Sensitive Information vulnerability in Drupal Drupal core allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Drupal core: from 8.0.0 before 10.4.9, from 10.5.0 before 10.5.6, from 11.0.0 before 11.1.9, from 11.2.0 before 11.2.8, from 7.0 before 7.103.

Statement: Red Hat Product Security has determined that this vulnerability does not affect any currently supported Red Hat product. This assessment may evolve based on further analysis and discovery. For more information about this vulnerability and the products it affects, please see the linked references.

Remediation:
org.apache.camel: Apache Camel: Camel Message Header Injection through request parameters
CVE: CVE-2025-29891
Component: camel-http
CWE: CWE-164
Severity: Moderate
CVSS v3: 6.5/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Release date: 2025-03-12T14:42:59.644000+00:00

Bypass/Injection vulnerability in Apache Camel.

This issue affects Apache Camel: from 4.10.0 before 4.10.2, from 4.8.0 before 4.8.5, from 3.10.0 before 3.22.4.

Users are recommended to upgrade to version 4.10.2 for 4.10.x LTS, 4.8.5 for 4.8.x LTS and 3.22.4 for 3.x releases.

This vulnerability is present in Camel's default incoming header filter, that allows an attacker to include Camel specific headers that for some Camel components can alter the behaviours such as the camel-bean component, or the camel-exec component.

If you have Camel applications that are directly connected to the internet via HTTP, then an attacker could include parameters in the HTTP requests that are sent to the Camel application that get translated into headers. 

The headers could be both provided as request parameters for an HTTP methods invocation or as part of the payload of the HTTP methods invocation.

All the known Camel HTTP component such as camel-servlet, camel-jetty, camel-undertow, camel-platform-http, and camel-netty-http would be vulnerable out of the box.

This CVE is related to the CVE-2025-27636: while they have the same root cause and are fixed with the same fix, CVE-2025-27636 was assumed to only be exploitable if an attacker could add malicious HTTP headers, while we have now determined that it is also exploitable via HTTP parameters. Like in CVE-2025-27636, exploitation is only possible if the Camel route uses particular vulnerable components.

Statement: This CVE is related to the CVE-2025-27636: while they have the same root cause and are fixed with the same fix, CVE-2025-27636 was assumed to only be exploitable if an attacker could add malicious HTTP headers, while we have now determined that it is also exploitable via HTTP parameters. Like in CVE-2025-27636, exploitation is only possible if the Camel route uses particular vulnerable components.

Remediation:
As a workaround, users could use removeHeaders EIP, to filter out anything like ‘cAmel, cAMEL’ etc, or in general everything not starting with ‘Camel’, ‘camel’ or ‘org.apache.camel.’.
Jenkins authorization token leak
CVE: CVE-2025-67638
Component: org.jenkins-ci.main/jenkins-core
CWE: CWE-312
Severity: Moderate
CVSS v3: 4.5/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Release date: 2025-12-10T16:50:37.570000+00:00

Jenkins 2.540 and earlier, LTS 2.528.2 and earlier does not mask build authorization tokens displayed on the job configuration form, increasing the potential for attackers to observe and capture them.


Remediation:
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
gpsd: Arbitrary code execution via heap-based out-of-bounds write in NMEA2000 packet handling
CVE: CVE-2025-67268
Component: gpsd
CWE: CWE-1285
Severity: Important
CVSS v3: 7.5/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-01-01T00:00:00+00:00

A flaw was found in gpsd. The hnd_129540 function, responsible for handling NMEA2000 PGN 129540 (GNSS Satellites in View) packets, fails to properly validate the user-supplied satellite count. A remote attacker can exploit this by sending a specially crafted packet with an excessive satellite count, leading to a heap-based out-of-bounds write. This memory corruption can result in a Denial of Service (DoS) and potentially allow for arbitrary code execution.

Statement: This vulnerability is rated Important rather than Moderate because it results in a heap-based out-of-bounds write triggered by untrusted, attacker-controlled input processed in a core parsing path of gpsd. The satellite count field from a PGN 129540 NMEA2000 Fast Packet is used directly as a loop bound without validation, allowing a single malformed packet to deterministically overwrite heap memory beyond the fixed-size skyview array. Unlike logic errors that only cause graceful failures, this condition introduces active memory corruption, which can destabilize the daemon, corrupt adjacent heap objects, and compromise internal session state in ways that are non-recoverable without a restart. The flaw is reachable pre-authentication, requires no brute force or sustained traffic, and can be reliably triggered with minimal attacker effort once CAN bus access is obtained.

Remediation:
Risk can be reduced by limiting exposure of gpsd to trusted NMEA2000/CAN bus sources only, ensuring that untrusted or externally reachable interfaces cannot inject crafted Fast Packets. Systems should avoid forwarding NMEA2000 traffic from bridged, virtualized, or containerized environments unless strict validation is in place, and gpsd should be run with least-privilege permissions to minimize the impact of a crash or corrupted state.
jfs: reject on-disk inodes of an unsupported type
CVE: CVE-2025-37925
Component: kernel
CWE: CWE-20
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-04-18T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

jfs: reject on-disk inodes of an unsupported type

Syzbot has reported the following BUG:

kernel BUG at fs/inode.c:668!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
RIP: 0010:clear_inode+0x168/0x190
Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7
 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7f
RSP: 0018:ffffc900027dfae8 EFLAGS: 00010093
RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980
RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38
R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000
R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80
FS:  0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 ? __die_body+0x5f/0xb0
 ? die+0x9e/0xc0
 ? do_trap+0x15a/0x3a0
 ? clear_inode+0x168/0x190
 ? do_error_trap+0x1dc/0x2c0
 ? clear_inode+0x168/0x190
 ? __pfx_do_error_trap+0x10/0x10
 ? report_bug+0x3cd/0x500
 ? handle_invalid_op+0x34/0x40
 ? clear_inode+0x168/0x190
 ? exc_invalid_op+0x38/0x50
 ? asm_exc_invalid_op+0x1a/0x20
 ? clear_inode+0x57/0x190
 ? clear_inode+0x167/0x190
 ? clear_inode+0x168/0x190
 ? clear_inode+0x167/0x190
 jfs_evict_inode+0xb5/0x440
 ? __pfx_jfs_evict_inode+0x10/0x10
 evict+0x4ea/0x9b0
 ? __pfx_evict+0x10/0x10
 ? iput+0x713/0xa50
 txUpdateMap+0x931/0xb10
 ? __pfx_txUpdateMap+0x10/0x10
 jfs_lazycommit+0x49a/0xb80
 ? _raw_spin_unlock_irqrestore+0x8f/0x140
 ? lockdep_hardirqs_on+0x99/0x150
 ? __pfx_jfs_lazycommit+0x10/0x10
 ? __pfx_default_wake_function+0x10/0x10
 ? __kthread_parkme+0x169/0x1d0
 ? __pfx_jfs_lazycommit+0x10/0x10
 kthread+0x2f2/0x390
 ? __pfx_jfs_lazycommit+0x10/0x10
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x4d/0x80
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 </TASK>

This happens when 'clear_inode()' makes an attempt to finalize an underlying
JFS inode of unknown type. According to JFS layout description from
https://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to
15 are reserved for future extensions and should not be encountered on a valid
filesystem. So add an extra check for valid inode type in 'copy_from_dinode()'.


Remediation:
nilfs2: handle errors that nilfs_prepare_chunk() may return
CVE: CVE-2025-21721
Component: kernel
Severity: None
Release date: 2025-02-27T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

nilfs2: handle errors that nilfs_prepare_chunk() may return

Patch series "nilfs2: fix issues with rename operations".

This series fixes BUG_ON check failures reported by syzbot around rename
operations, and a minor behavioral issue where the mtime of a child
directory changes when it is renamed instead of moved.


This patch (of 2):

The directory manipulation routines nilfs_set_link() and
nilfs_delete_entry() rewrite the directory entry in the folio/page
previously read by nilfs_find_entry(), so error handling is omitted on the
assumption that nilfs_prepare_chunk(), which prepares the buffer for
rewriting, will always succeed for these.  And if an error is returned, it
triggers the legacy BUG_ON() checks in each routine.

This assumption is wrong, as proven by syzbot: the buffer layer called by
nilfs_prepare_chunk() may call nilfs_get_block() if necessary, which may
fail due to metadata corruption or other reasons.  This has been there all
along, but improved sanity checks and error handling may have made it more
reproducible in fuzzing tests.

Fix this issue by adding missing error paths in nilfs_set_link(),
nilfs_delete_entry(), and their caller nilfs_rename().


Remediation:
rv: Fully convert enabled_monitors to use list_head as iterator
CVE: CVE-2025-40232
Component: kernel
Severity: Low
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-12-04T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

rv: Fully convert enabled_monitors to use list_head as iterator

The callbacks in enabled_monitors_seq_ops are inconsistent. Some treat the
iterator as struct rv_monitor *, while others treat the iterator as struct
list_head *.

This causes a wrong type cast and crashes the system as reported by Nathan.

Convert everything to use struct list_head * as iterator. This also makes
enabled_monitors consistent with available_monitors.


Remediation:
XSS in Stackrox
CVE: CVE-2025-5198
Component: stackrox
CWE: CWE-79
Severity: Moderate
CVSS v3: 5.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L
Release date: 2025-05-26T00:00:00+00:00

A flaw was found in Stackrox, where it is vulnerable to Cross-site scripting (XSS) if the script code is included in a small subset of table cells. The only known potential exploit is if the script is included in the name of a Kubernetes “Role” object* that is applied to a secured cluster. This object can be used by a user with access to the cluster or through a compromised third-party product.


Remediation:
Currently, no mitigation is available for this vulnerability.
af_packet: move notifier's packet_dev_mc out of rcu critical section
CVE: CVE-2025-38150
Component: kernel
CWE: CWE-821
Severity: Moderate
CVSS v3: 5.6/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-07-03T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

af_packet: move notifier's packet_dev_mc out of rcu critical section

Syzkaller reports the following issue:

 BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578
 __mutex_lock+0x106/0xe80 kernel/locking/mutex.c:746
 team_change_rx_flags+0x38/0x220 drivers/net/team/team_core.c:1781
 dev_change_rx_flags net/core/dev.c:9145 [inline]
 __dev_set_promiscuity+0x3f8/0x590 net/core/dev.c:9189
 netif_set_promiscuity+0x50/0xe0 net/core/dev.c:9201
 dev_set_promiscuity+0x126/0x260 net/core/dev_api.c:286 packet_dev_mc net/packet/af_packet.c:3698 [inline]
 packet_dev_mclist_delete net/packet/af_packet.c:3722 [inline]
 packet_notifier+0x292/0xa60 net/packet/af_packet.c:4247
 notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85
 call_netdevice_notifiers_extack net/core/dev.c:2214 [inline]
 call_netdevice_notifiers net/core/dev.c:2228 [inline]
 unregister_netdevice_many_notify+0x15d8/0x2330 net/core/dev.c:11972
 rtnl_delete_link net/core/rtnetlink.c:3522 [inline]
 rtnl_dellink+0x488/0x710 net/core/rtnetlink.c:3564
 rtnetlink_rcv_msg+0x7cf/0xb70 net/core/rtnetlink.c:6955
 netlink_rcv_skb+0x219/0x490 net/netlink/af_netlink.c:2534

Calling `PACKET_ADD_MEMBERSHIP` on an ops-locked device can trigger
the `NETDEV_UNREGISTER` notifier, which may require disabling promiscuous
and/or allmulti mode. Both of these operations require acquiring
the netdev instance lock.

Move the call to `packet_dev_mc` outside of the RCU critical section.
The `mclist` modifications (add, del, flush, unregister) are protected by
the RTNL, not the RCU. The RCU only protects the `sklist` and its
associated `sks`. The delayed operation on the `mclist` entry remains
within the RTNL.


Remediation:
Missing permission check allows retrieving secrets from agent configurations
CVE: CVE-2025-31721
Component: jenkins
CWE: CWE-862
Severity: Moderate
CVSS v3: 5.9/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
Release date: 2025-04-02T14:59:50.144000+00:00

A missing permission check in Jenkins 2.503 and earlier, LTS 2.492.2 and earlier allows attackers with Computer/Create permission but without Computer/Configure permission to copy an agent, gaining access to encrypted secrets in its configuration.


Remediation:
net: stmmac: fix the crash issue for zero copy XDP_TX action
CVE: CVE-2025-71095
Component: kernel
Severity: None
Release date: 2025-01-01T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

net: stmmac: fix the crash issue for zero copy XDP_TX action

There is a crash issue when running zero copy XDP_TX action, the crash
log is shown below.

[  216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000
[  216.187524] Internal error: Oops: 0000000096000144 [#1]  SMP
[  216.301694] Call trace:
[  216.304130]  dcache_clean_poc+0x20/0x38 (P)
[  216.308308]  __dma_sync_single_for_device+0x1bc/0x1e0
[  216.313351]  stmmac_xdp_xmit_xdpf+0x354/0x400
[  216.317701]  __stmmac_xdp_run_prog+0x164/0x368
[  216.322139]  stmmac_napi_poll_rxtx+0xba8/0xf00
[  216.326576]  __napi_poll+0x40/0x218
[  216.408054] Kernel panic - not syncing: Oops: Fatal exception in interrupt

For XDP_TX action, the xdp_buff is converted to xdp_frame by
xdp_convert_buff_to_frame(). The memory type of the resulting xdp_frame
depends on the memory type of the xdp_buff. For page pool based xdp_buff
it produces xdp_frame with memory type MEM_TYPE_PAGE_POOL. For zero copy
XSK pool based xdp_buff it produces xdp_frame with memory type
MEM_TYPE_PAGE_ORDER0. However, stmmac_xdp_xmit_back() does not check the
memory type and always uses the page pool type, this leads to invalid
mappings and causes the crash. Therefore, check the xdp_buff memory type
in stmmac_xdp_xmit_back() to fix this issue.


Remediation:
drm/xe/migrate: don't overflow max copy size
CVE: CVE-2025-39741
Component: kernel
Severity: None
Release date: 2025-09-11T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

drm/xe/migrate: don't overflow max copy size

With non-page aligned copy, we need to use 4 byte aligned pitch, however
the size itself might still be close to our maximum of ~8M, and so the
dimensions of the copy can easily exceed the S16_MAX limit of the copy
command leading to the following assert:

xe 0000:03:00.0: [drm] Assertion `size / pitch <= ((s16)(((u16)~0U) >> 1))` failed!
platform: BATTLEMAGE subplatform: 1
graphics: Xe2_HPG 20.01 step A0
media: Xe2_HPM 13.01 step A1
tile: 0 VRAM 10.0 GiB
GT: 0 type 1

WARNING: CPU: 23 PID: 10605 at drivers/gpu/drm/xe/xe_migrate.c:673 emit_copy+0x4b5/0x4e0 [xe]

To fix this account for the pitch when calculating the number of current
bytes to copy.

(cherry picked from commit 8c2d61e0e916e077fda7e7b8e67f25ffe0f361fc)


Remediation:
LoongArch: BPF: Don't override subprog's return value
CVE: CVE-2025-22048
Component: kernel
Severity: None
Release date: 2025-04-16T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

LoongArch: BPF: Don't override subprog's return value

The verifier test `calls: div by 0 in subprog` triggers a panic at the
ld.bu instruction. The ld.bu insn is trying to load byte from memory
address returned by the subprog. The subprog actually set the correct
address at the a5 register (dedicated register for BPF return values).
But at commit 73c359d1d356 ("LoongArch: BPF: Sign-extend return values")
we also sign extended a5 to the a0 register (return value in LoongArch).
For function call insn, we later propagate the a0 register back to a5
register. This is right for native calls but wrong for bpf2bpf calls
which expect zero-extended return value in a5 register. So only move a0
to a5 for native calls (i.e. non-BPF_PSEUDO_CALL).


Remediation:
dm thin: make get_first_thin use rcu-safe list first function
CVE: CVE-2025-21664
Component: kernel
CWE: CWE-20
Severity: Moderate
CVSS v3: 5.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-01-21T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

dm thin: make get_first_thin use rcu-safe list first function

The documentation in rculist.h explains the absence of list_empty_rcu()
and cautions programmers against relying on a list_empty() ->
list_first() sequence in RCU safe code.  This is because each of these
functions performs its own READ_ONCE() of the list head.  This can lead
to a situation where the list_empty() sees a valid list entry, but the
subsequent list_first() sees a different view of list head state after a
modification.

In the case of dm-thin, this author had a production box crash from a GP
fault in the process_deferred_bios path.  This function saw a valid list
head in get_first_thin() but when it subsequently dereferenced that and
turned it into a thin_c, it got the inside of the struct pool, since the
list was now empty and referring to itself.  The kernel on which this
occurred printed both a warning about a refcount_t being saturated, and
a UBSAN error for an out-of-bounds cpuid access in the queued spinlock,
prior to the fault itself.  When the resulting kdump was examined, it
was possible to see another thread patiently waiting in thin_dtr's
synchronize_rcu.

The thin_dtr call managed to pull the thin_c out of the active thins
list (and have it be the last entry in the active_thins list) at just
the wrong moment which lead to this crash.

Fortunately, the fix here is straight forward.  Switch get_first_thin()
function to use list_first_or_null_rcu() which performs just a single
READ_ONCE() and returns NULL if the list is already empty.

This was run against the devicemapper test suite's thin-provisioning
suites for delete and suspend and no regressions were observed.


Remediation: