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

spi: microchip-core-qspi: stop checking viability of op->max_freq in supports_op callback

In commit[PII_REDACTED]3d9 ("spi: microchip-core-qspi: Support per spi-mem
operation frequency switches") the logic for checking the viability of
op->max_freq in mchp_coreqspi_setup_clock() was copied into
mchp_coreqspi_supports_op(). Unfortunately, op->max_freq is not valid
when this function is called during probe but is instead zero.
Accordingly, baud_rate_val is calculated to be INT_MAX due to division
by zero, causing probe of the attached memory device to fail.

Seemingly spi-microchip-core-qspi was the only driver that had such a
modification made to its supports_op callback when the per_op_freq
capability was added, so just remove it to restore prior functionality.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/89e7353f522f5cf70cb48c01ce2dcdcb275b8022; https://git.kernel.org/stable/c/ac8a13f35d5b8996582b3f97b924838a5c570c18
CVE: CVE-2025-39922
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ixgbe: fix incorrect map used in eee linkmode

incorrectly used ixgbe_lp_map in loops intended to populate the
supported and advertised EEE linkmode bitmaps based on ixgbe_ls_map.
This results in incorrect bit setting and potential out-of-bounds
access, since ixgbe_lp_map and ixgbe_ls_map have different sizes
and purposes.

ixgbe_lp_map[i] -> ixgbe_ls_map[i]

Use ixgbe_ls_map for supported and advertised linkmodes, and keep
ixgbe_lp_map usage only for link partner (lp_advertised) mapping.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/129c1cb8a081a02d99267cb51708f1326395f4e8; https://git.kernel.org/stable/c/682105ab63826fb7ca7c112b42b478d156fbb19f; https://git.kernel.org/stable/c/b7e5c3e3bfa9dc8af75ff6d8633ad7070e1985e4
CVE: CVE-2025-39923
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees

When we don't have a clock specified in the device tree, we have no way to
ensure the BAM is on. This is often the case for remotely-controlled or
remotely-powered BAM instances. In this case, we need to read num-channels
from the DT to have all the necessary information to complete probing.

However, at the moment invalid device trees without clock and without
num-channels still continue probing, because the error handling is missing
return statements. The driver will then later try to read the number of
channels from the registers. This is unsafe, because it relies on boot
firmware and lucky timing to succeed. Unfortunately, the lack of proper
error handling here has been abused for several Qualcomm SoCs upstream,
causing early boot crashes in several situations [1, 2].

Avoid these early crashes by erroring out when any of the required DT
properties are missing. Note that this will break some of the existing DTs
upstream (mainly BAM instances related to the crypto engine). However,
clearly these DTs have never been tested properly, since the error in the
kernel log was just ignored. It's safer to disable the crypto engine for
these broken DTBs.

[1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/
[2]: https://lore.kernel.org/r/[PII_REDACTED]5959.646747-1-krzysztof.kozlowski@linaro.org/
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0ff9df758af7022d749718fb6b8385cc5693acf3; https://git.kernel.org/stable/c/1d98ba204d8a6db0d986c7f1aefaa0dcd1c007a2; https://git.kernel.org/stable/c/1fc14731f0be4885e60702b9596d14d9a79cf053
CVE: CVE-2025-39924
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

erofs: fix invalid algorithm for encoded extents

The current algorithm sanity checks do not properly apply to new
encoded extents.

Unify the algorithm check with Z_EROFS_COMPRESSION(_RUNTIME)_MAX
and ensure consistency with sbi->available_compr_algs.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/131897c65e2b86cf14bec7379f44aa8fbb407526; https://git.kernel.org/stable/c/db5d7abd379a8dcf030be8f52f99cadf7e397ba8
CVE: CVE-2025-39925
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

can: j1939: implement NETDEV_UNREGISTER notification handler

syzbot is reporting

  unregister_netdevice: waiting for vcan0 to become free. Usage count = 2

problem, for j1939 protocol did not have NETDEV_UNREGISTER notification
handler for undoing changes made by j1939_sk_bind().

Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destruct
callback") expects that a call to j1939_priv_put() can be unconditionally
delayed until j1939_sk_sock_destruct() is called. But we need to call
j1939_priv_put() against an extra ref held by j1939_sk_bind() call
(as a part of undoing changes made by j1939_sk_bind()) as soon as
NETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct()
is called via j1939_sk_release()). Otherwise, the extra ref on "struct
j1939_priv" held by j1939_sk_bind() call prevents "struct net_device" from
dropping the usage count to 1; making it impossible for
unregister_netdevice() to continue.

[mkl: remove space in front of label]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7fcbe5b2c6a4b5407bf2241fdb71e0a390f6ab9a; https://git.kernel.org/stable/c/da9e8f[PII_REDACTED]70407e8f90559b5d46c20262
CVE: CVE-2025-39926
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

genetlink: fix genl_bind() invoking bind() after -EPERM

Per family bind/unbind callbacks were introduced to allow families
to track multicast group consumer presence, e.g. to start or stop
producing events depending on listeners.

However, in genl_bind() the bind() callback was invoked even if
capability checks failed and ret was set to -EPERM. This means that
callbacks could run on behalf of unauthorized callers while the
syscall still returned failure to user space.

Fix this by only invoking bind() after "if (ret) break;" check
i.e. after permission checks have succeeded.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1dbfb0363224f6da56f6655d596dc5097308d6f5; https://git.kernel.org/stable/c/8858c1e9405906c09589d7c336f04058ea198207; https://git.kernel.org/stable/c/98c9d884047a3051c203708914a874dece3cbe54
CVE: CVE-2025-39927
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ceph: fix race condition validating r_parent before applying state

Add validation to ensure the cached parent directory inode matches the
directory info in MDS replies. This prevents client-side race conditions
where concurrent operations (e.g. rename) cause r_parent to become stale
between request initiation and reply processing, which could lead to
applying state changes to incorrect directory inodes.

[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to
  move CEPH_CAP_PIN reference when r_parent is updated:

  When the parent directory lock is not held, req->r_parent can become
  stale and is updated to point to the correct inode.  However, the
  associated CEPH_CAP_PIN reference was not being adjusted.  The
  CEPH_CAP_PIN is a reference on an inode that is tracked for
  accounting purposes.  Moving this pin is important to keep the
  accounting balanced. When the pin was not moved from the old parent
  to the new one, it created two problems: The reference on the old,
  stale parent was never released, causing a reference leak.
  A reference for the new parent was never acquired, creating the risk
  of a reference underflow later in ceph_mdsc_release_request().  This
  patch corrects the logic by releasing the pin from the old parent and
  acquiring it for the new parent when r_parent is switched.  This
  ensures reference accounting stays balanced. ]
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-362
References: https://git.kernel.org/stable/c/15f519e9f883b316d86e2bb6b767a023aafd9d83; https://git.kernel.org/stable/c/2bfe45987eb346e299d9f763f9cd05f77011519f; https://git.kernel.org/stable/c/db378e6f83ec705c6091c65d482d555edc2b0a72
CVE: CVE-2025-39928
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

i2c: rtl9300: ensure data length is within supported range

Add an explicit check for the xfer length to 'rtl9300_i2c_config_xfer'
to ensure the data length isn't within the supported range. In
particular a data length of 0 is not supported by the hardware and
causes unintended or destructive behaviour.

This limitation becomes obvious when looking at the register
documentation [1]. 4 bits are reserved for DATA_WIDTH and the value
of these 4 bits is used as N + 1, allowing a data length range of
1 <= len <= 16.

Affected by this is the SMBus Quick Operation which works with a data
length of 0. Passing 0 as the length causes an underflow of the value
due to:

(len - 1) & 0xf

and effectively specifying a transfer length of 16 via the registers.
This causes a 16-byte write operation instead of a Quick Write. For
example, on SFP modules without write-protected EEPROM this soft-bricks
them by overwriting some initial bytes.

For completeness, also add a quirk for the zero length.

[1] https://svanheule.net/realtek/longan/register/i2c_mst1_ctrl2
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-191, CWE-191
References: https://git.kernel.org/stable/c/06418cb5a1a542a003fdb4ad8e76ea542d57cfba; https://git.kernel.org/stable/c/c91382328fc89f73144d5582f2d8f1dd3e41c8f7
CVE: CVE-2025-61622
Published: 2025-10-01
Description: Deserialization of untrusted data in python in pyfory versions 0.12.0 through 0.12.2, or the legacy pyfury versions from 0.1.0 through 0.10.3: allows arbitrary code execution. An application is vulnerable if it reads pyfory serialized data from untrusted sources. An attacker can craft a data stream that selects pickle-fallback serializer during deserialization, leading to the execution of `pickle.loads`, which is vulnerable to remote code execution.

Users are recommended to upgrade to pyfory version 0.12.3 or later, which has removed pickle fallback serializer and thus fixes this issue.
CVSS Score: 9.8 (CRITICAL)
CWE: CWE-502
References: https://lists.apache.org/thread/vfn9hp9qt06db5yo1gmj3l114o3o2csd; http://www.openwall.com/lists/oss-security/2025/09/29/3
CVE: CVE-2025-10847
Published: 2025-10-01
Description: DX Unified Infrastructure Management (Nimsoft/UIM) and below contains an improper ACL handling vulnerability in the robot (controller) component. A remote attacker can execute commands, read from, or write to the target system.
CWE: CWE-284
References: https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36180
CVE: CVE-2021-4460
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Fix UBSAN shift-out-of-bounds warning

If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up
doing a shift operation where the number of bits shifted equals
number of bits in the operand. This behaviour is undefined.

Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the
count is >= number of bits in the operand.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472
CVSS Score: 7.1 (HIGH)
CWE: CWE-125, CWE-125
References: https://git.kernel.org/stable/c/0c0356ef2498c1a250fe3846f30293f828737309; https://git.kernel.org/stable/c/1874b0ef1426b873de94c61861e38f29a8df714c; https://git.kernel.org/stable/c/3fdc[PII_REDACTED]a685d23df57d65166e8556a266
CVE: CVE-2022-50420
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: hisilicon/hpre - fix resource leak in remove process

In hpre_remove(), when the disable operation of qm sriov failed,
the following logic should continue to be executed to release the
remaining resources that have been allocated, instead of returning
directly, otherwise there will be resource leakage.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/2b3e3ecdb402ff1053ee25b598ff21b9ddf4384f; https://git.kernel.org/stable/c/45e6319bd5f2154d8b8c9f1eaa4ac030ba0d330c; https://git.kernel.org/stable/c/4e0de941d252d4e7c985981e78480c8d6f020b64
CVE: CVE-2022-50421
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

rpmsg: char: Avoid double destroy of default endpoint

The rpmsg_dev_remove() in rpmsg_core is the place for releasing
this default endpoint.

So need to avoid destroying the default endpoint in
rpmsg_chrdev_eptdev_destroy(), this should be the same as
rpmsg_eptdev_release(). Otherwise there will be double destroy
issue that ept->refcount report warning:

refcount_t: underflow; use-after-free.

Call trace:
 refcount_warn_saturate+0xf8/0x150
 virtio_rpmsg_destroy_ept+0xd4/0xec
 rpmsg_dev_remove+0x60/0x70

The issue can be reproduced by stopping remoteproc before
closing the /dev/rpmsgX.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/3f20ef7a845c2c8d7ec82ecffa20d95cab5ecfeb; https://git.kernel.org/stable/c/467233a4ac29b215d492843d067a9f091e6bf0c5; https://git.kernel.org/stable/c/ef828a39d6a7028836eaf37df3ad568c8c2dd6f9
CVE: CVE-2022-50422
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: libsas: Fix use-after-free bug in smp_execute_task_sg()

When executing SMP task failed, the smp_execute_task_sg() calls del_timer()
to delete "slow_task->timer". However, if the timer handler
sas_task_internal_timedout() is running, the del_timer() in
smp_execute_task_sg() will not stop it and a UAF will happen. The process
is shown below:

      (thread 1)               |        (thread 2)
smp_execute_task_sg()          | sas_task_internal_timedout()
 ...                           |
 del_timer()                   |
 ...                           |  ...
 sas_free_task(task)           |
  kfree(task->slow_task) //FREE|
                               |  task->slow_task->... //USE

Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure
the timer handler have finished before the "task->slow_task" is
deallocated.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/117331a2a5227fb4369c2a1f321d3e3e2e2ef8fe; https://git.kernel.org/stable/c/2e12ce270f0d926085c1209cc90397e307deef97; https://git.kernel.org/stable/c/46ba53c30666717cb06c2b3c5d896301cd00d0c0
CVE: CVE-2022-50423
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()

There is an use-after-free reported by KASAN:

  BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82
  Read of size 1 at addr ffff888112afc460 by task modprobe/2111
  CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
  Call Trace:
   <TASK>
   kasan_report+0xae/0xe0
   acpi_ut_remove_reference+0x3b/0x82
   acpi_ut_copy_iobject_to_iobject+0x3be/0x3d5
   acpi_ds_store_object_to_local+0x15d/0x3a0
   acpi_ex_store+0x78d/0x7fd
   acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b
   acpi_ps_parse_aml+0x217/0x8d5
   ...
   </TASK>

The root cause of the problem is that the acpi_operand_object
is freed when acpi_ut_walk_package_tree() fails in
acpi_ut_copy_ipackage_to_ipackage(), lead to repeated release in
acpi_ut_copy_iobject_to_iobject(). The problem was introduced
by "8aa5e56eeb61" commit, this commit is to fix memory leak in
acpi_ut_copy_iobject_to_iobject(), repeatedly adding remove
operation, lead to "acpi_operand_object" used after free.

Fix it by removing acpi_ut_remove_reference() in
acpi_ut_copy_ipackage_to_ipackage(). acpi_ut_copy_ipackage_to_ipackage()
is called to copy an internal package object into another internal
package object, when it fails, the memory of acpi_operand_object
should be freed by the caller.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416, CWE-416
References: https://git.kernel.org/stable/c/01f2c2052ea50fb9a8ce12e4e83aed0267934ef0; https://git.kernel.org/stable/c/02617006b5a46f2ea55ac61f5693c7afd7bf9276; https://git.kernel.org/stable/c/02f237423c9c6a18e062de2d474f85d5659e4eb9
CVE: CVE-2022-50424
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7921: resource leaks at mt7921_check_offload_capability()

Fixed coverity issue with resource leaks at variable "fw" going out of
scope leaks the storage it points to mt7921_check_offload_capability().

Addresses-Coverity-ID: 1527806 ("Resource leaks")
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/47180ecf[PII_REDACTED]c5307c1d5526f8ac6a5a6d; https://git.kernel.org/stable/c/ead3cffd7510dc635d84cd4ea9dd1974fcb69a35
CVE: CVE-2022-50425
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly

When an extended state component is not present in fpstate, but in init
state, the function copies from init_fpstate via copy_feature().

But, dynamic states are not present in init_fpstate because of all-zeros
init states. Then retrieving them from init_fpstate will explode like this:

 BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
 ...
 RIP: 0010:memcpy_erms+0x6/0x10
  ? __copy_xstate_to_uabi_buf+0x381/0x870
  fpu_copy_guest_fpstate_to_uabi+0x28/0x80
  kvm_arch_vcpu_ioctl+0x14c/0x1460 [kvm]
  ? __this_cpu_preempt_check+0x13/0x20
  ? vmx_vcpu_put+0x2e/0x260 [kvm_intel]
  kvm_vcpu_ioctl+0xea/0x6b0 [kvm]
  ? kvm_vcpu_ioctl+0xea/0x6b0 [kvm]
  ? __fget_light+0xd4/0x130
  __x64_sys_ioctl+0xe3/0x910
  ? debug_smp_processor_id+0x17/0x20
  ? fpregs_assert_state_consistent+0x27/0x50
  do_syscall_64+0x3f/0x90
  entry_SYSCALL_64_after_hwframe+0x63/0xcd

Adjust the 'mask' to zero out the userspace buffer for the features that
are not available both from fpstate and from init_fpstate.

The dynamic features depend on the compacted XSAVE format. Ensure it is
enabled before reading XCOMP_BV in init_fpstate.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/471f0aa7fa64e23766a1473b32d9ec3f0718895a; https://git.kernel.org/stable/c/6ff29642fd28965a8f8d6d326ac91bf6075f3113
CVE: CVE-2022-50426
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

remoteproc: imx_dsp_rproc: Add mutex protection for workqueue

The workqueue may execute late even after remoteproc is stopped or
stopping, some resources (rpmsg device and endpoint) have been
released in rproc_stop_subdevices(), then rproc_vq_interrupt()
accessing these resources will cause kennel dump.

Call trace:
 virtqueue_add_split+0x1ac/0x560
 virtqueue_add_inbuf+0x4c/0x60
 rpmsg_recv_done+0x15c/0x294
 vring_interrupt+0x6c/0xa4
 rproc_vq_interrupt+0x30/0x50
 imx_dsp_rproc_vq_work+0x24/0x40 [imx_dsp_rproc]
 process_one_work+0x1d0/0x354
 worker_thread+0x13c/0x470
 kthread+0x154/0x160
 ret_from_fork+0x10/0x20

Add mutex protection in imx_dsp_rproc_vq_work(), if the state is
not running, then just skip calling rproc_vq_interrupt().

Also the flush workqueue operation can't be added in rproc stop
for the same reason. The call sequence is

rproc_shutdown
-> rproc_stop
   ->rproc_stop_subdevices
   ->rproc->ops->stop()
     ->imx_dsp_rproc_stop
       ->flush_work
         -> rproc_vq_interrupt

The resource needed by rproc_vq_interrupt has been released in
rproc_stop_subdevices, so flush_work is not safe to be called in
imx_dsp_rproc_stop.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/47e6ab07018edebf94ce873cf50a05ec76ff2dde; https://git.kernel.org/stable/c/4a3e1fa7a77838617bdbcd95127ce93a959fad44; https://git.kernel.org/stable/c/b9693304b7133b81741add5bfb56f022596df012
CVE: CVE-2022-50427
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: ac97: fix possible memory leak in snd_ac97_dev_register()

If device_register() fails in snd_ac97_dev_register(), it should
call put_device() to give up reference, or the name allocated in
dev_set_name() is leaked.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0f8e9a15c8ecf95057061d370a2dddaf1cee4aeb; https://git.kernel.org/stable/c/4881bda5ea05c8c240fc8afeaa928e2bc43f61fa; https://git.kernel.org/stable/c/4fdf6f978c6b605ca0d67bf0e982b7a8fc0f4aab
CVE: CVE-2022-50428
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix off-by-one errors in fast-commit block filling

Due to several different off-by-one errors, or perhaps due to a late
change in design that wasn't fully reflected in the code that was
actually merged, there are several very strange constraints on how
fast-commit blocks are filled with tlv entries:

- tlvs must start at least 10 bytes before the end of the block, even
  though the minimum tlv length is 8.  Otherwise, the replay code will
  ignore them.  (BUG: ext4_fc_reserve_space() could violate this
  requirement if called with a len of blocksize - 9 or blocksize - 8.
  Fortunately, this doesn't seem to happen currently.)

- tlvs must end at least 1 byte before the end of the block.  Otherwise
  the replay code will consider them to be invalid.  This quirk
  contributed to a bug (fixed by an earlier commit) where uninitialized
  memory was being leaked to disk in the last byte of blocks.

Also, strangely these constraints don't apply to the replay code in
e2fsprogs, which will accept any tlvs in the blocks (with no bounds
checks at all, but that is a separate issue...).

Given that this all seems to be a bug, let's fix it by just filling
blocks with tlv entries in the natural way.

Note that old kernels will be unable to replay fast-commit journals
created by kernels that have this commit.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-193
References: https://git.kernel.org/stable/c/18f28f13301d1afb8cea9c4ddcecdbff14488ec6; https://git.kernel.org/stable/c/48a6a66db82b8043d298a630f22c62d43550cae5; https://git.kernel.org/stable/c/5439ad45c0d0c8db41eb6f4dce6f778f15a5ee16
CVE: CVE-2022-50429
Published: 2025-10-01
Description: In the Linux kernel, the following vulnerability has been resolved:

memory: of: Fix refcount leak bug in of_lpddr3_get_ddr_timings()

We should add the of_node_put() when breaking out of
for_each_child_of_node() as it will automatically increase
and decrease the refcount.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1d312c12c91f831fcc48623c921f2d4560edb159; https://git.kernel.org/stable/c/3b321bf7687968a090cf6b62bd8e67d692f59a16; https://git.kernel.org/stable/c/48af14fb0eaa63d9aa68f59fb0b205ec55a95636