deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-39705
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: fix a Null pointer dereference vulnerability

[Why]
A null pointer dereference vulnerability exists in the AMD display driver's
(DC module) cleanup function dc_destruct().
When display control context (dc->ctx) construction fails
(due to memory allocation failure), this pointer remains NULL.
During subsequent error handling when dc_destruct() is called,
there's no NULL check before dereferencing the perf_trace member
(dc->ctx->perf_trace), causing a kernel null pointer dereference crash.

[How]
Check if dc->ctx is non-NULL before dereferencing.

(Updated commit text and removed unnecessary error message)
(cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0961673cc5f0055957aa46f25eb4ef6c07e00165; https://git.kernel.org/stable/c/1bcf63a44381691d[PII_REDACTED]f830ce3250e367; https://git.kernel.org/stable/c/4ade995b9b25b3c6e8dc42c27070340f1358d8c8
CVE: CVE-2025-39706
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdkfd: Destroy KFD debugfs after destroy KFD wq

Since KFD proc content was moved to kernel debugfs, we can't destroy KFD
debugfs before kfd_process_destroy_wq. Move kfd_process_destroy_wq prior
to kfd_debugfs_fini to fix a kernel NULL pointer problem. It happens
when /sys/kernel/debug/kfd was already destroyed in kfd_debugfs_fini but
kfd_process_destroy_wq calls kfd_debugfs_remove_process. This line
    debugfs_remove_recursive(entry->proc_dentry);
tries to remove /sys/kernel/debug/kfd/proc/<pid> while
/sys/kernel/debug/kfd is already gone. It hangs the kernel by kernel
NULL pointer.

(cherry picked from commit 0333052d90683d88531558dcfdbf2525cc37c233)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2e58401a24e7b2d4ec619104e1a76590c1284a4c; https://git.kernel.org/stable/c/74ee7445c3b61c3bd899a54bd82c1982cb3a8206; https://git.kernel.org/stable/c/910735ded17cc306625e7e1cdcc8102f7ac60994
CVE: CVE-2025-39707
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: check if hubbub is NULL in debugfs/amdgpu_dm_capabilities

HUBBUB structure is not initialized on DCE hardware, so check if it is NULL
to avoid null dereference while accessing amdgpu_dm_capabilities file in
debugfs.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/83cfdc2b018cd9c0f927b781d4e07c0d4a911fac; https://git.kernel.org/stable/c/98e92fceb9507901e3e8b550e93b843306abd354; https://git.kernel.org/stable/c/b4a69f7f29c8a459ad6b4d8a8b72450f1d9fd288
CVE: CVE-2025-39708
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

media: iris: Fix NULL pointer dereference

A warning reported by smatch indicated a possible null pointer
dereference where one of the arguments to API
"iris_hfi_gen2_handle_system_error" could sometimes be null.

To fix this, add a check to validate that the argument passed is not
null before accessing its members.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0f837559ccdd275c5a059e6ac4d5034b03409f1d; https://git.kernel.org/stable/c/992ddee3c0da5f113ba86892ace467c1ac645538
CVE: CVE-2025-39709
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

media: venus: protect against spurious interrupts during probe

Make sure the interrupt handler is initialized before the interrupt is
registered.

If the IRQ is registered before hfi_create(), it's possible that an
interrupt fires before the handler setup is complete, leading to a NULL
dereference.

This error condition has been observed during system boot on Rb3Gen2.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/18c2b2bd982b8546312c9a[PII_REDACTED]169f28e0; https://git.kernel.org/stable/c/3200144a2fa4209dc084a19941b9b203b43580f0; https://git.kernel.org/stable/c/37cc0ac889b018097c217c5929fd6dc2aed636a1
CVE: CVE-2025-39710
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

media: venus: Add a check for packet size after reading from shared memory

Add a check to ensure that the packet size does not exceed the number of
available words after reading the packet header from shared memory. This
ensures that the size provided by the firmware is safe to process and
prevent potential out-of-bounds memory access.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0520c89f6280d2b60ab537d[PII_REDACTED]ee7d8ab; https://git.kernel.org/stable/c/2d8cea8310a245730816a1fd0c9fa4a5a3bdc68c; https://git.kernel.org/stable/c/49befc830daa743e051a65468c05c2ff9e8580e6
CVE: CVE-2025-39711
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() calls

Both the ACE and CSI driver are missing a mei_cldev_disable() call in
their remove() function.

This causes the mei_cl client to stay part of the mei_device->file_list
list even though its memory is freed by mei_cl_bus_dev_release() calling
kfree(cldev->cl).

This leads to a use-after-free when mei_vsc_remove() runs mei_stop()
which first removes all mei bus devices calling mei_ace_remove() and
mei_csi_remove() followed by mei_cl_bus_dev_release() and then calls
mei_cl_all_disconnect() which walks over mei_device->file_list dereferecing
the just freed cldev->cl.

And mei_vsc_remove() it self is run at shutdown because of the
platform_device_unregister(tp->pdev) in vsc_tp_shutdown()

When building a kernel with KASAN this leads to the following KASAN report:

[ 106.634504] ==================================================================
[ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei
[ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1
[ 106.634729]
[ 106.634767] Tainted: [E]=UNSIGNED_MODULE
[ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025
[ 106.634773] Call Trace:
[ 106.634777]  <TASK>
...
[ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)
[ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei
[ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei
[ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei
...
[ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei
[ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc
[ 106.635066] platform_remove (drivers/base/platform.c:1424)

Add the missing mei_cldev_disable() calls so that the mei_cl gets removed
from mei_device->file_list before it is freed to fix this.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0c92c49fc688cfadacc47ae99b06a31237702e9e; https://git.kernel.org/stable/c/1dfe73394dcfc9b049c8da0dc181c45f156a5f49; https://git.kernel.org/stable/c/3c0e4cc4f55f9a1db2a761e4ffb27c[PII_REDACTED]
CVE: CVE-2025-39712
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

media: mt9m114: Fix deadlock in get_frame_interval/set_frame_interval

Getting / Setting the frame interval using the V4L2 subdev pad ops
get_frame_interval/set_frame_interval causes a deadlock, as the
subdev state is locked in the [1] but also in the driver itself.

In [2] it's described that the caller is responsible to acquire and
release the lock in this case. Therefore, acquiring the lock in the
driver is wrong.

Remove the lock acquisitions/releases from mt9m114_ifp_get_frame_interval()
and mt9m114_ifp_set_frame_interval().

[1] drivers/media/v4l2-core/v4l2-subdev.c - line 1129
[2] Documentation/driver-api/media/v4l2-subdev.rst
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0d23b548d71e5d76955fdf1d73addd8f6494f602; https://git.kernel.org/stable/c/298d1471cf83d5a2a05970e41822a2403f451086; https://git.kernel.org/stable/c/41b97490a1656bdc7038d6345a84b08d45deafc6
CVE: CVE-2025-39713
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()

In the interrupt handler rain_interrupt(), the buffer full check on
rain->buf_len is performed before acquiring rain->buf_lock. This
creates a Time-of-Check to Time-of-Use (TOCTOU) race condition, as
rain->buf_len is concurrently accessed and modified in the work
handler rain_irq_work_handler() under the same lock.

Multiple interrupt invocations can race, with each reading buf_len
before it becomes full and then proceeding. This can lead to both
interrupts attempting to write to the buffer, incrementing buf_len
beyond its capacity (DATA_SIZE) and causing a buffer overflow.

Fix this bug by moving the spin_lock() to before the buffer full
check. This ensures that the check and the subsequent buffer modification
are performed atomically, preventing the race condition. An corresponding
spin_unlock() is added to the overflow path to correctly release the
lock.

This possible bug was found by an experimental static analysis tool
developed by our team.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-367
References: https://git.kernel.org/stable/c/1c2769dc[PII_REDACTED]2ea5a4ff1a07dcdeb1603f; https://git.kernel.org/stable/c/2964dbe631fd21ad7873b1752b895548d3c12496; https://git.kernel.org/stable/c/3c3e33b7edca7a2d6a96801f287f9faeb684d655
CVE: CVE-2025-39714
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

media: usbtv: Lock resolution while streaming

When an program is streaming (ffplay) and another program (qv4l2)
changes the TV standard from NTSC to PAL, the kernel crashes due to trying
to copy to unmapped memory.

Changing from NTSC to PAL increases the resolution in the usbtv struct,
but the video plane buffer isn't adjusted, so it overflows.

[hverkuil: call vb2_is_busy instead of vb2_is_streaming]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3d83d0b5ae5045a7a246ed116b5f6c688a12f9e9; https://git.kernel.org/stable/c/5427dda195d6baf23028196fd55a0c90f66ffa61; https://git.kernel.org/stable/c/7e40e0bb778907b2441bff68d73c3eb6b6cd319f
CVE: CVE-2025-39715
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

parisc: Revise gateway LWS calls to probe user read access

We use load and stbys,e instructions to trigger memory reference
interruptions without writing to memory. Because of the way read
access support is implemented, read access interruptions are only
triggered at privilege levels 2 and 3. The kernel and gateway
page execute at privilege level 0, so this code never triggers
a read access interruption. Thus, it is currently possible for
user code to execute a LWS compare and swap operation at an
address that is read protected at privilege level 3 (PRIV_USER).

Fix this by probing read access rights at privilege level 3 and
branching to lws_fault if access isn't allowed.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/8bccf47adbf658293528e86960e6d6f736b1c9f7; https://git.kernel.org/stable/c/9b6af875baba9c4679b55f4561e[PII_REDACTED]05f; https://git.kernel.org/stable/c/bc0a24c24ceebabb5ba65900e332233d79e625e6
CVE: CVE-2025-39716
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

parisc: Revise __get_user() to probe user read access

Because of the way read access support is implemented, read access
interruptions are only triggered at privilege levels 2 and 3. The
kernel executes at privilege level 0, so __get_user() never triggers
a read access interruption (code 26). Thus, it is currently possible
for user code to access a read protected address via a system call.

Fix this by probing read access rights at privilege level 3 (PRIV_USER)
and setting __gu_err to -EFAULT (-14) if access isn't allowed.

Note the cmpiclr instruction does a 32-bit compare because COND macro
doesn't work inside asm.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/28a9b71671fb4a2993ef85b8ef6f117ea63894fe; https://git.kernel.org/stable/c/4c981077255acc2ed5b3df6e8dd0125c81b626a9; https://git.kernel.org/stable/c/741b163e440683195b8fd4fc8495fcd0105c6ab7
CVE: CVE-2025-39717
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

open_tree_attr: do not allow id-mapping changes without OPEN_TREE_CLONE

As described in commit 7a54947e727b ('Merge patch series "fs: allow
changing idmappings"'), open_tree_attr(2) was necessary in order to
allow for a detached mount to be created and have its idmappings changed
without the risk of any racing threads operating on it. For this reason,
mount_setattr(2) still does not allow for id-mappings to be changed.

However, there was a bug in commit 2462651ffa76 ("fs: allow changing
idmappings") which allowed users to bypass this restriction by calling
open_tree_attr(2) *without* OPEN_TREE_CLONE.

can_idmap_mount() prevented this bug from allowing an attached
mountpoint's id-mapping from being modified (thanks to an is_anon_ns()
check), but this still allows for detached (but visible) mounts to have
their be id-mapping changed. This risks the same UAF and locking issues
as described in the merge commit, and was likely unintentional.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/69dbdc711d[PII_REDACTED]e3830191a6afffa0a1f0; https://git.kernel.org/stable/c/9308366f062129d52e0ee3f7a019f7dd41db33df
CVE: CVE-2025-39718
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

vsock/virtio: Validate length in packet header before skb_put()

When receiving a vsock packet in the guest, only the virtqueue buffer
size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately,
virtio_vsock_skb_rx_put() uses the length from the packet header as the
length argument to skb_put(), potentially resulting in SKB overflow if
the host has gone wonky.

Validate the length as advertised by the packet header before calling
virtio_vsock_skb_rx_put().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0dab[PII_REDACTED]7b82e8e0455839eaf5ac7bf894; https://git.kernel.org/stable/c/676f03760ca1d69c2470cef36c44dc152494b47c; https://git.kernel.org/stable/c/969b06bd8b7560efb100a34227619e7d318fbe05
CVE: CVE-2025-39719
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: imu: bno055: fix OOB access of hw_xlate array

Fix a potential out-of-bounds array access of the hw_xlate array in
bno055.c.

In bno055_get_regmask(), hw_xlate was iterated over the length of the
vals array instead of the length of the hw_xlate array. In the case of
bno055_gyr_scale, the vals array is larger than the hw_xlate array,
so this could result in an out-of-bounds access. In practice, this
shouldn't happen though because a match should always be found which
breaks out of the for loop before it iterates beyond the end of the
hw_xlate array.

By adding a new hw_xlate_len field to the bno055_sysfs_attr, we can be
sure we are iterating over the correct length.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/399b883ec828e436f1a721bf8551b4da8727e65b; https://git.kernel.org/stable/c/4808ca3aa30ae857454d0b41d2d0bf161a312b45; https://git.kernel.org/stable/c/50e823a23816b792daf6e8405f8d6045952bb90e
CVE: CVE-2025-39720
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix refcount leak causing resource not released

When ksmbd_conn_releasing(opinfo->conn) returns true,the refcount was not
decremented properly, causing a refcount leak that prevents the count from
reaching zero and the memory from being released.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/36e010bb865fbaa1202fe9bcce3fd486d6db7606; https://git.kernel.org/stable/c/89bb430f621124af39bb31763c4a8b504c9651e2; https://git.kernel.org/stable/c/9a7abce6e8c0e2145b346a6d4abf0d9655e9b0e8
CVE: CVE-2025-39721
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - flush misc workqueue during device shutdown

Repeated loading and unloading of a device specific QAT driver, for
example qat_4xxx, in a tight loop can lead to a crash due to a
use-after-free scenario. This occurs when a power management (PM)
interrupt triggers just before the device-specific driver (e.g.,
qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains
loaded.

Since the driver uses a shared workqueue (`qat_misc_wq`) across all
devices and owned by intel_qat.ko, a deferred routine from the
device-specific driver may still be pending in the queue. If this
routine executes after the driver is unloaded, it can dereference freed
memory, resulting in a page fault and kernel crash like the following:

    BUG: unable to handle page fault for address: ffa000002e50a01c
    #PF: supervisor read access in kernel mode
    RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]
    Call Trace:
      pm_bh_handler+0x1d2/0x250 [intel_qat]
      process_one_work+0x171/0x340
      worker_thread+0x277/0x3a0
      kthread+0xf0/0x120
      ret_from_fork+0x2d/0x50

To prevent this, flush the misc workqueue during device shutdown to
ensure that all pending work items are completed before the driver is
unloaded.

Note: This approach may slightly increase shutdown latency if the
workqueue contains jobs from other devices, but it ensures correctness
and stability.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3d4df408ba9bad2b205c7fb8afc1836a6a4ca88a; https://git.kernel.org/stable/c/5858448a6c65d8ee3f8600570d3ce19febcb33be; https://git.kernel.org/stable/c/e59a52e429e13df3feb34f4853a8e36d121ed937
CVE: CVE-2025-39722
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULP

Since the CAAM on these SoCs is managed by another ARM core, called the
SECO (Security Controller) on iMX8QM and Secure Enclave on iMX8ULP, which
also reserves access to register page 0 suspend operations cannot touch
this page.

This is similar to when running OPTEE, where OPTEE will reserve page 0.

Track this situation using a new state variable no_page0, reflecting if
page 0 is reserved elsewhere, either by other management cores in SoC or
by OPTEE.

Replace the optee_en check in suspend/resume with the new check.

optee_en cannot go away as it's needed elsewhere to gate OPTEE specific
situations.

Fixes the following splat at suspend:

    Internal error: synchronous external abort: [PII_REDACTED] [#1] SMP
    Hardware name: Freescale i.MX8QXP ACU6C (DT)
    pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : readl+0x0/0x18
    lr : rd_reg32+0x18/0x3c
    sp : ffffffc08192ba20
    x29: ffffffc08192ba20 x28: ffffff[PII_REDACTED] x27: [PII_REDACTED]
    x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090
    x23: [PII_REDACTED] x22: ffffffc080922000 x21: ffffff8020e89010
    x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5
    x17:[PII_REDACTED]f35963 x16: 000000008f785f3f x15: 000000003b8ef57c
    x14: 00000000c418aef8 x13: 00000000f5fea526 x12: [PII_REDACTED]
    x11: [PII_REDACTED] x10: [PII_REDACTED] x9 : [PII_REDACTED]
    x8 : ffffff[PII_REDACTED] x7 : ffffff[PII_REDACTED] x6 : [PII_REDACTED]
    x5 : ffffff80217268f0 x4 : ffffff[PII_REDACTED] x3 : ffffffc081200000
    x2 : [PII_REDACTED] x1 : ffffff8020e89010 x0 : ffffffc081200004
    Call trace:
     readl+0x0/0x18
     caam_ctrl_suspend+0x30/0xdc
     dpm_run_callback.constprop.0+0x24/0x5c
     device_suspend+0x170/0x2e8
     dpm_suspend+0xa0/0x104
     dpm_suspend_start+0x48/0x50
     suspend_devices_and_enter+0x7c/0x45c
     pm_suspend+0x148/0x160
     state_store+0xb4/0xf8
     kobj_attr_store+0x14/0x24
     sysfs_kf_write+0x38/0x48
     kernfs_fop_write_iter+0xb4/0x178
     vfs_write+0x118/0x178
     ksys_write+0x6c/0xd0
     __arm64_sys_write+0x14/0x1c
     invoke_syscall.constprop.0+0x64/0xb0
     do_el0_svc+0x90/0xb0
     el0_svc+0x18/0x44
     el0t_64_sync_handler+0x88/0x124
     el0t_64_sync+0x150/0x154
    Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/488ed465e579a20485f38080e4ef8b90b69ef7c0; https://git.kernel.org/stable/c/5ffc47feddcf8eb4d8ac7b42111a02c8e8146512; https://git.kernel.org/stable/c/f9534674ce53f133c91c272f091f[PII_REDACTED]ae
CVE: CVE-2025-39723
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

netfs: Fix unbuffered write error handling

If all the subrequests in an unbuffered write stream fail, the subrequest
collector doesn't update the stream->transferred value and it retains its
initial LONG_MAX value.  Unfortunately, if all active streams fail, then we
take the smallest value of { LONG_MAX, LONG_MAX, ... } as the value to set
in wreq->transferred - which is then returned from ->write_iter().

LONG_MAX was chosen as the initial value so that all the streams can be
quickly assessed by taking the smallest value of all stream->transferred -
but this only works if we've set any of them.

Fix this by adding a flag to indicate whether the value in
stream->transferred is valid and checking that when we integrate the
values.  stream->transferred can then be initialised to zero.

This was found by running the generic/750 xfstest against cifs with
cache=none.  It splices data to the target file.  Once (if) it has used up
all the available scratch space, the writes start failing with ENOSPC.
This causes ->write_iter() to fail.  However, it was returning
wreq->transferred, i.e. LONG_MAX, rather than an error (because it thought
the amount transferred was non-zero) and iter_file_splice_write() would
then try to clean up that amount of pipe bufferage - leading to an oops
when it overran.  The kernel log showed:

    CIFS: VFS: Send error in write = -28

followed by:

    BUG: kernel NULL pointer dereference, address: [PII_REDACTED]

with:

    RIP: 0010:iter_file_splice_write+0x3a4/0x520
    do_splice+0x197/0x4e0

or:

    RIP: 0010:pipe_buf_release (include/linux/pipe_fs_i.h:282)
    iter_file_splice_write (fs/splice.c:755)

Also put a warning check into splice to announce if ->write_iter() returned
that it had written more than it was asked to.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/387164a2b97e1f5404c6d0049a7409bac7d2bc5b; https://git.kernel.org/stable/c/a3de58b12ce074ec05b8741fa28d62ccb1070468; https://git.kernel.org/stable/c/f08c80af3c9a9849cd178b4843b7c01d103506a1