huzaifas-sidhpurwala/RedHat-security-VeX huggingface dataset:
bnxt_en: Mask the bd_cnt field in the TX BD properly
CVE: CVE-2025-22108
Component: kernel
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-04-16T00:00:00+00:00

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

bnxt_en: Mask the bd_cnt field in the TX BD properly

The bd_cnt field in the TX BD specifies the total number of BDs for
the TX packet.  The bd_cnt field has 5 bits and the maximum number
supported is 32 with the value 0.

CONFIG_MAX_SKB_FRAGS can be modified and the total number of SKB
fragments can approach or exceed the maximum supported by the chip.
Add a macro to properly mask the bd_cnt field so that the value 32
will be properly masked and set to 0 in the bd_cnd field.

Without this patch, the out-of-range bd_cnt value will corrupt the
TX BD and may cause TX timeout.

The next patch will check for values exceeding 32.

Statement: Only local user can trigger this bug. Need to modify the value of CONFIG_MAX_SKB_FRAGS to trigger it. For the Red Hat Enterprise Linux with the default value of the CONFIG_MAX_SKB_FRAGS would be complex to trigger. The security impact is limited to the deny of service (if would be possible to trigger it).

Remediation:
To mitigate this issue, prevent module bnxt_en from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically.
rcu: Fix rcu_read_unlock() deadloop due to IRQ work
CVE: CVE-2025-39744
Component: kernel
Severity: None
Release date: 2025-09-11T00:00:00+00:00

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

rcu: Fix rcu_read_unlock() deadloop due to IRQ work

During rcu_read_unlock_special(), if this happens during irq_exit(), we
can lockup if an IPI is issued. This is because the IPI itself triggers
the irq_exit() path causing a recursive lock up.

This is precisely what Xiongfeng found when invoking a BPF program on
the trace_tick_stop() tracepoint As shown in the trace below. Fix by
managing the irq_work state correctly.

irq_exit()
  __irq_exit_rcu()
    /* in_hardirq() returns false after this */
    preempt_count_sub(HARDIRQ_OFFSET)
    tick_irq_exit()
      tick_nohz_irq_exit()
	    tick_nohz_stop_sched_tick()
	      trace_tick_stop()  /* a bpf prog is hooked on this trace point */
		   __bpf_trace_tick_stop()
		      bpf_trace_run2()
			    rcu_read_unlock_special()
                              /* will send a IPI to itself */
			      irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);

A simple reproducer can also be obtained by doing the following in
tick_irq_exit(). It will hang on boot without the patch:

  static inline void tick_irq_exit(void)
  {
 +	rcu_read_lock();
 +	WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true);
 +	rcu_read_unlock();
 +

[neeraj: Apply Frederic's suggested fix for PREEMPT_RT]


Remediation:
mm/zswap: fix inconsistency when zswap_store_page() fails
CVE: CVE-2025-21860
Component: kernel
CWE: CWE-99
Severity: Low
CVSS v3: 3.4/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Release date: 2025-03-12T00:00:00+00:00

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

mm/zswap: fix inconsistency when zswap_store_page() fails

Commit b7c0ccdfbafd ("mm: zswap: support large folios in zswap_store()")
skips charging any zswap entries when it failed to zswap the entire folio.

However, when some base pages are zswapped but it failed to zswap the
entire folio, the zswap operation is rolled back.  When freeing zswap
entries for those pages, zswap_entry_free() uncharges the zswap entries
that were not previously charged, causing zswap charging to become
inconsistent.

This inconsistency triggers two warnings with following steps:
  # On a machine with 64GiB of RAM and 36GiB of zswap
  $ stress-ng --bigheap 2 # wait until the OOM-killer kills stress-ng
  $ sudo reboot

  The two warnings are:
    in mm/memcontrol.c:163, function obj_cgroup_release():
      WARN_ON_ONCE(nr_bytes & (PAGE_SIZE - 1));

    in mm/page_counter.c:60, function page_counter_cancel():
      if (WARN_ONCE(new < 0, "page_counter underflow: %ld nr_pages=%lu\n",
	  new, nr_pages))

zswap_stored_pages also becomes inconsistent in the same way.

As suggested by Kanchana, increment zswap_stored_pages and charge zswap
entries within zswap_store_page() when it succeeds.  This way,
zswap_entry_free() will decrement the counter and uncharge the entries
when it failed to zswap the entire folio.

While this could potentially be optimized by batching objcg charging and
incrementing the counter, let's focus on fixing the bug this time and
leave the optimization for later after some evaluation.

After resolving the inconsistency, the warnings disappear.

[42.hyeyoo@gmail.com: refactor zswap_store_page()]


Remediation:
Remote crash of vllm server with invalid regex
CVE: CVE-2025-48943
Component: vllm
CWE: CWE-248
Severity: Moderate
CVSS v3: 4.5/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L
Release date: 2025-05-30T18:36:01.519000+00:00

An application level denial of service flaw was found in vLLM. This flaw allows a remote attacker with access to the system prompt to submit an invalid regular expression while requesting structured output and crash the vLLM instance.

Statement: The severity of this vulnerability is rated Moderate, as it does not impact system availability. The effects are confined to the application layer, without compromising the underlying system stability.

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.
Plack-Middleware-Session insecure session ids
CVE: CVE-2025-40923
Component: plack-middleware-session
CVSS v3: 5.3/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Release date: 2025-07-16T13:05:03.782000+00:00

A random session id generation flaw has been discovered in Plack-Middleware-Session. By default, session ids are generated by a SHA-1 hash seeded with the built-in rand function, the epoch time, and the PID. The PID will come from a small set of numbers, and the epoch time may be guessed if it is not leaked from the HTTP Date header. Predicable session ids could allow an attacker to gain access to systems.

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:
thunderbird: Race condition in the Graphics component
CVE: CVE-2025-13012
Component: firefox
CWE: CWE-366
Severity: Important
CVSS v3: 7.5/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Release date: 2025-11-11T15:47:11.434000+00:00

A flaw was found in Firefox and Thunderbird. The Mozilla Foundation's Security Advisory describes the following issue: Race condition in the Graphics component.

Statement: Red Hat Product Security rates the severity of this flaw as determined by the Mozilla Foundation Security Advisory.

Remediation:
software node: Correct a OOB check in software_node_get_reference_args()
CVE: CVE-2025-38342
Component: kernel
CWE: CWE-125
Severity: Moderate
CVSS v3: 5.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N
Release date: 2025-07-10T00:00:00+00:00

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

software node: Correct a OOB check in software_node_get_reference_args()

software_node_get_reference_args() wants to get @index-th element, so
the property value requires at least '(index + 1) * sizeof(*ref)' bytes
but that can not be guaranteed by current OOB check, and may cause OOB
for malformed property.

Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.

Statement: Exploiting this vulnerability requires the ability to craft or manipulate firmware node properties from kernel space. Such operations typically require high privileges, such as loading kernel modules or using in-kernel interfaces. Therefore, the vulnerability is not accessible to unprivileged users and is classified as Privileges Required: High (PR:H).

Remediation:
DDL unspecified vulnerability (CPU Jan 2025)
CVE: CVE-2025-21499
Component: mysql
Severity: Moderate
CVSS v3: 5.9/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
Release date: 2025-01-21T20:52:55.284000+00:00

Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.4.3 and prior and  9.1.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).


Remediation:
Erlang Excessive Resource Consumption
CVE: CVE-2025-48040
Component: erlang
CWE: CWE-770
Severity: Moderate
CVSS v3: 5.3/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Release date: 2025-09-11T08:14:19.671000+00:00

Uncontrolled Resource Consumption vulnerability in Erlang OTP ssh (ssh_sftp modules) allows Excessive Allocation, Flooding. This vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl.

This issue affects OTP form OTP 17.0 until OTP 28.0.3, OTP 27.3.4.3 and 26.2.5.15 corresponding to ssh from 3.0.1 until 5.3.3, 5.2.11.3 and 5.1.4.12.


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.
Linux kernel (btrfs): Denial of Service due to unexpected metadata generation
CVE: CVE-2025-39800
Component: kernel
CWE: CWE-390
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-09-15T00:00:00+00:00

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

btrfs: abort transaction on unexpected eb generation at btrfs_copy_root()

If we find an unexpected generation for the extent buffer we are cloning
at btrfs_copy_root(), we just WARN_ON() and don't error out and abort the
transaction, meaning we allow to persist metadata with an unexpected
generation. Instead of warning only, abort the transaction and return
-EUCLEAN.


Remediation:
hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()
CVE: CVE-2025-38712
Component: kernel
Severity: None
Release date: 2025-09-04T00:00:00+00:00

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

hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()

When the volume header contains erroneous values that do not reflect
the actual state of the filesystem, hfsplus_fill_super() assumes that
the attributes file is not yet created, which later results in hitting
BUG_ON() when hfsplus_create_attributes_file() is called. Replace this
BUG_ON() with -EIO error with a message to suggest running fsck tool.


Remediation:
can: peak_usb: fix shift-out-of-bounds issue
CVE: CVE-2025-40020
Component: kernel
CWE: CWE-682
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-10-24T00:00:00+00:00

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

can: peak_usb: fix shift-out-of-bounds issue

Explicitly uses a 64-bit constant when the number of bits used for its
shifting is 32 (which is the case for PC CAN FD interfaces supported by
this driver).

[mkl: update subject, apply manually]

Statement: The fix changes 1 to 1ULL so the operation occurs in 64-bit space, preventing overflow.
The impact is limited to incorrect timestamp calculations or potential driver instability when using PEAK-System CAN-USB FD adapters.

Remediation:
mm: fix uprobe pte be overwritten when expanding vma
CVE: CVE-2025-38207
Component: kernel
CWE: CWE-911
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-04T00:00:00+00:00

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

mm: fix uprobe pte be overwritten when expanding vma

Patch series "Fix uprobe pte be overwritten when expanding vma".


This patch (of 4):

We encountered a BUG alert triggered by Syzkaller as follows:
   BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1

And we can reproduce it with the following steps:
1. register uprobe on file at zero offset
2. mmap the file at zero offset:
   addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0);
3. mremap part of vma1 to new vma2:
   addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE);
4. mremap back to orig addr1:
   mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1);

In step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2
with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1
to vma2, then unmap the vma1 range [addr1, addr1 + 4096].

In step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the
addr range [addr1, addr1 + 4096].  Since the addr range [addr1 + 4096,
addr1 + 8192] still maps the file, it will take vma_merge_new_range to
expand the range, and then do uprobe_mmap in vma_complete.  Since the
merged vma pgoff is also zero offset, it will install uprobe anon page to
the merged vma.  However, the upcomming move_page_tables step, which use
set_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite
the newly uprobe pte in the merged vma, and lead that pte to be orphan.

Since the uprobe pte will be remapped to the merged vma, we can remove the
unnecessary uprobe_mmap upon merged vma.

This problem was first found in linux-6.6.y and also exists in the
community syzkaller:
https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/


Remediation:
Redis: Authenticated users can execute LUA scripts as a different user
CVE: CVE-2025-46818
Component: Redis
CWE: CWE-94
Severity: Moderate
CVSS v3: 6.0/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N
Release date: 2025-10-03T18:38:57.170000+00:00

A code injection vulnerability in Redis Lua scripting where an authenticated user can craft a Lua script to manipulate objects and potentially execute code in another user’s context.

Statement: This rated Moderate as the vulnerability requires authenticated access with scripting rights, high-complexity steps to trigger a specific Lua code path, and typically another user action for cross-context execution. The impact is confined to the Redis process and data, with no availability effect, and can be mitigated via standard ACLs restricting EVAL/FUNCTION or by updating to the fixed release. Unlike “Important” flaws, it is not remotely exploitable without interaction or across trust boundaries.

This flaw exists only in the Redis server implementation; 

Redis client libraries (Python, Node.js, Rust, etc.) are not affected by this vulnerability, and it only exists in the Redis server’s embedded Lua engine where scripts execute. Client libraries merely transmit EVAL/EVALSHA to the server.

Remediation:
No mitigation is currently available that meets Red Hat Product Security’s standards for usability, deployment, applicability, or stability.

To reduce the risk, restricting network access to trusted hosts, enforcing strong authentication and protected-mode, disabling or limiting Lua scripting where possible can be be benificial and apply least-privilege ACLs to reduce who can run scripting commands, keep instances non-public with firewalls/VPCs, and follow Redis hardening guidance to minimize exposure.
media: nxp: imx8-isi: m2m: Fix streaming cleanup on release
CVE: CVE-2025-40165
Component: kernel
Severity: None
Release date: 2025-11-12T00:00:00+00:00

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

media: nxp: imx8-isi: m2m: Fix streaming cleanup on release

If streamon/streamoff calls are imbalanced, such as when exiting an
application with Ctrl+C when streaming, the m2m usage_count will never
reach zero and the ISI channel won't be freed. Besides from that, if the
input line width is more than 2K, it will trigger a WARN_ON():

[ 59.222120] ------------[ cut here ]------------
[ 59.226758] WARNING: drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c:631 at mxc_isi_channel_chain+0xa4/0x120, CPU#4: v4l2-ctl/654
[ 59.238569] Modules linked in: ap1302
[ 59.242231] CPU: 4 UID: 0 PID: 654 Comm: v4l2-ctl Not tainted 6.16.0-rc4-next-20250704-06511-gff0e002d480a-dirty #258 PREEMPT
[ 59.253597] Hardware name: NXP i.MX95 15X15 board (DT)
[ 59.258720] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 59.265669] pc : mxc_isi_channel_chain+0xa4/0x120
[ 59.270358] lr : mxc_isi_channel_chain+0x44/0x120
[ 59.275047] sp : ffff8000848c3b40
[ 59.278348] x29: ffff8000848c3b40 x28: ffff0000859b4c98 x27: ffff800081939f00
[ 59.285472] x26: 000000000000000a x25: ffff0000859b4cb8 x24: 0000000000000001
[ 59.292597] x23: ffff0000816f4760 x22: ffff0000816f4258 x21: ffff000084ceb780
[ 59.299720] x20: ffff000084342ff8 x19: ffff000084340000 x18: 0000000000000000
[ 59.306845] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffdb369e1c
[ 59.313969] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[ 59.321093] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
[ 59.328217] x8 : ffff8000848c3d48 x7 : ffff800081930b30 x6 : ffff800081930b30
[ 59.335340] x5 : ffff0000859b6000 x4 : ffff80008193ae80 x3 : ffff800081022420
[ 59.342464] x2 : ffff0000852f6900 x1 : 0000000000000001 x0 : ffff000084341000
[ 59.349590] Call trace:
[ 59.352025]  mxc_isi_channel_chain+0xa4/0x120 (P)
[ 59.356722]  mxc_isi_m2m_streamon+0x160/0x20c
[ 59.361072]  v4l_streamon+0x24/0x30
[ 59.364556]  __video_do_ioctl+0x40c/0x4a0
[ 59.368560]  video_usercopy+0x2bc/0x690
[ 59.372382]  video_ioctl2+0x18/0x24
[ 59.375857]  v4l2_ioctl+0x40/0x60
[ 59.379168]  __arm64_sys_ioctl+0xac/0x104
[ 59.383172]  invoke_syscall+0x48/0x104
[ 59.386916]  el0_svc_common.constprop.0+0xc0/0xe0
[ 59.391613]  do_el0_svc+0x1c/0x28
[ 59.394915]  el0_svc+0x34/0xf4
[ 59.397966]  el0t_64_sync_handler+0xa0/0xe4
[ 59.402143]  el0t_64_sync+0x198/0x19c
[ 59.405801] ---[ end trace 0000000000000000 ]---

Address this issue by moving the streaming preparation and cleanup to
the vb2 .prepare_streaming() and .unprepare_streaming() operations. This
also simplifies the driver by allowing direct usage of the
v4l2_m2m_ioctl_streamon() and v4l2_m2m_ioctl_streamoff() helpers.


Remediation:
OAuth2-Proxy authentication bypass
CVE: CVE-2025-54576
Component: github.com/oauth2-proxy/oauth2-proxy
CWE: CWE-290
Severity: Important
CVSS v3: 7.4/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Release date: 2025-07-30T19:41:04.189000+00:00

An authentication bypass flaw was found in the OAuth2-Proxy project. This bypass affects systems that have configured their deployment to skip authentication on endpoints that match a deployment-defined regular expression. HTTP parameters can be used to match and trigger the authentication bypass in unexpected ways.

Statement: This vulnerability only affects deployments that have manually configured the `skip_auth_routes` option with a regular expression. This is not a default configuration on Red Hat systems and so the impact is assessed to be important rather than critical.

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.
MediaWiki: Cross-site Scripting (XSS) via improper input neutralization
CVE: CVE-2025-61638
Component: MediaWiki
CVSS v3: 4.8/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N
Release date: 2025-01-01T00:00:00+00:00

A flaw was found in MediaWiki. This vulnerability, identified as Cross-site Scripting (XSS), allows a remote attacker to inject malicious scripts into web pages due to improper neutralization of input during web page generation. When a user views an affected page, the malicious code can execute in their browser, potentially leading to information disclosure or unauthorized actions.

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:
Libcurl .netrc Credential Leak via Redirect
CVE: CVE-2025-0167
Component: libcurl
CVSS v3: 3.6/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
Release date: 2025-02-05T09:15:06.891000+00:00

A flaw was found in Curl. This vulnerability allows an attacker to obtain leaked credentials via HTTP redirects when using a .netrc file with a default entry that omits the login and password.

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:
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.
cnic: Fix use-after-free bugs in cnic_delete_task
CVE: CVE-2025-39945
Component: kernel
CWE: CWE-362
Severity: Moderate
CVSS v3: 5.9/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H
Release date: 2025-10-04T00:00:00+00:00

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

cnic: Fix use-after-free bugs in cnic_delete_task

The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),
which does not guarantee that the delayed work item 'delete_task' has
fully completed if it was already running. Additionally, the delayed work
item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only
blocks and waits for work items that were already queued to the
workqueue prior to its invocation. Any work items submitted after
flush_workqueue() is called are not included in the set of tasks that the
flush operation awaits. This means that after the cyclic work items have
finished executing, a delayed work item may still exist in the workqueue.
This leads to use-after-free scenarios where the cnic_dev is deallocated
by cnic_free_dev(), while delete_task remains active and attempt to
dereference cnic_dev in cnic_delete_task().

A typical race condition is illustrated below:

CPU 0 (cleanup)              | CPU 1 (delayed work callback)
cnic_netdev_event()          |
  cnic_stop_hw()             | cnic_delete_task()
    cnic_cm_stop_bnx2x_hw()  | ...
      cancel_delayed_work()  | /* the queue_delayed_work()
      flush_workqueue()      |    executes after flush_workqueue()*/
                             | queue_delayed_work()
  cnic_free_dev(dev)//free   | cnic_delete_task() //new instance
                             |   dev = cp->dev; //use

Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the cyclic delayed work item is properly canceled and that any
ongoing execution of the work item completes before the cnic_dev is
deallocated. Furthermore, since cancel_delayed_work_sync() uses
__flush_work(work, true) to synchronously wait for any currently
executing instance of the work item to finish, the flush_workqueue()
becomes redundant and should be removed.

This bug was identified through static analysis. To reproduce the issue
and validate the fix, I simulated the cnic PCI device in QEMU and
introduced intentional delays — such as inserting calls to ssleep()
within the cnic_delete_task() function — to increase the likelihood
of triggering the bug.

Statement: The bug in CNIC allowed a race between device cleanup and the cyclic delayed work delete_task, causing a use-after-free of cnic_dev. The issue can only be triggered locally with elevated privileges (e.g., during device unload or shutdown) and primarily results in a kernel crash.

Remediation: