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

tls: fix handling of zero-length records on the rx_list

Each recvmsg() call must process either
 - only contiguous DATA records (any number of them)
 - one non-DATA record

If the next record has different type than what has already been
processed we break out of the main processing loop. If the record
has already been decrypted (which may be the case for TLS 1.3 where
we don't know type until decryption) we queue the pending record
to the rx_list. Next recvmsg() will pick it up from there.

Queuing the skb to rx_list after zero-copy decrypt is not possible,
since in that case we decrypted directly to the user space buffer,
and we don't have an skb to queue (darg.skb points to the ciphertext
skb for access to metadata like length).

Only data records are allowed zero-copy, and we break the processing
loop after each non-data record. So we should never zero-copy and
then find out that the record type has changed. The corner case
we missed is when the initial record comes from rx_list, and it's
zero length.
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/2902c3ebcca52ca845c03182000e8d71d3a5196f; https://git.kernel.org/stable/c/29c0ce3c8cdb6dc5d61139c937f34cb888a6f42e; https://git.kernel.org/stable/c/3439c15ae91a517cf3c650ea15a[PII_REDACTED]ad9
CVE: CVE-2025-39683
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

tracing: Limit access to parser->buffer when trace_get_user failed

When the length of the string written to set_ftrace_filter exceeds
FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:

BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0
Read of size 1 at addr ffff0000d00bd5ba by task ash/165

CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty
Hardware name: linux,dummy-virt (DT)
Call trace:
 show_stack+0x34/0x50 (C)
 dump_stack_lvl+0xa0/0x158
 print_address_description.constprop.0+0x88/0x398
 print_report+0xb0/0x280
 kasan_report+0xa4/0xf0
 __asan_report_load1_noabort+0x20/0x30
 strsep+0x18c/0x1b0
 ftrace_process_regex.isra.0+0x100/0x2d8
 ftrace_regex_release+0x484/0x618
 __fput+0x364/0xa58
 ____fput+0x28/0x40
 task_work_run+0x154/0x278
 do_notify_resume+0x1f0/0x220
 el0_svc+0xec/0xf0
 el0t_64_sync_handler+0xa0/0xe8
 el0t_64_sync+0x1ac/0x1b0

The reason is that trace_get_user will fail when processing a string
longer than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0.
Then an OOB access will be triggered in ftrace_regex_release->
ftrace_process_regex->strsep->strpbrk. We can solve this problem by
limiting access to parser->buffer when trace_get_user failed.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/3079517a5ba80901fe828a06998da64b9b8749be; https://git.kernel.org/stable/c/418b448e1d7470da9d4d4797f71782595ee69c49; https://git.kernel.org/stable/c/41b[PII_REDACTED]02f21918df66764b6fbf829d330
CVE: CVE-2025-39684
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()

syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`.  A kernel
buffer is allocated to hold `insn->n` samples (each of which is an
`unsigned int`).  For some instruction types, `insn->n` samples are
copied back to user-space, unless an error code is being returned.  The
problem is that not all the instruction handlers that need to return
data to userspace fill in the whole `insn->n` samples, so that there is
an information leak.  There is a similar syzbot report for
`do_insnlist_ioctl()`, although it does not have a reproducer for it at
the time of writing.

One culprit is `insn_rw_emulate_bits()` which is used as the handler for
`INSN_READ` or `INSN_WRITE` instructions for subdevices that do not have
a specific handler for that instruction, but do have an `INSN_BITS`
handler.  For `INSN_READ` it only fills in at most 1 sample, so if
`insn->n` is greater than 1, the remaining `insn->n - 1` samples copied
to userspace will be uninitialized kernel data.

Another culprit is `vm80xx_ai_insn_read()` in the "vm80xx" driver.  It
never returns an error, even if it fails to fill the buffer.

Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making sure
that uninitialized parts of the allocated buffer are zeroed before
handling each instruction.

Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`.  That fix
replaced the call to `kmalloc_array()` with `kcalloc()`, but it is not
always necessary to clear the whole buffer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/3cd212e895ca2d58963fdc6422502b10dd3966bb; https://git.kernel.org/stable/c/868a1b68dcd9f2805bb86aa64862402f785d8c4a; https://git.kernel.org/stable/c/aecf0d557ddd95ce68193a5ee1dc4c87415ff08a
CVE: CVE-2025-39685
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

comedi: pcl726: Prevent invalid irq number

The reproducer passed in an irq number(0x80008000) that was too large,
which triggered the oob.

Added an interrupt number check to prevent users from passing in an irq
number that was too large.

If `it->options[1]` is 31, then `1 << it->options[1]` is still invalid
because it shifts a 1-bit into the sign bit (which is UB in C).
Possible solutions include reducing the upper bound on the
`it->options[1]` value to 30 or lower, or using `1U << it->options[1]`.

The old code would just not attempt to request the IRQ if the
`options[1]` value were invalid.  And it would still configure the
device without interrupts even if the call to `request_irq` returned an
error.  So it would be better to combine this test with the test below.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0eb4ed2aa261dee228f1668dbfa6d87353e8162d; https://git.kernel.org/stable/c/5a33d07c94ba91306093e823112a7aa9727549f6; https://git.kernel.org/stable/c/96cb948408b3adb69df7e451ba7da9d21f814d00
CVE: CVE-2025-39686
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

comedi: Make insn_rw_emulate_bits() do insn->n samples

The `insn_rw_emulate_bits()` function is used as a default handler for
`INSN_READ` instructions for subdevices that have a handler for
`INSN_BITS` but not for `INSN_READ`.  Similarly, it is used as a default
handler for `INSN_WRITE` instructions for subdevices that have a handler
for `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the
`INSN_READ` or `INSN_WRITE` instruction handling with a constructed
`INSN_BITS` instruction.  However, `INSN_READ` and `INSN_WRITE`
instructions are supposed to be able read or write multiple samples,
indicated by the `insn->n` value, but `insn_rw_emulate_bits()` currently
only handles a single sample.  For `INSN_READ`, the comedi core will
copy `insn->n` samples back to user-space.  (That triggered KASAN
kernel-infoleak errors when `insn->n` was greater than 1, but that is
being fixed more generally elsewhere in the comedi core.)

Make `insn_rw_emulate_bits()` either handle `insn->n` samples, or return
an error, to conform to the general expectation for `INSN_READ` and
`INSN_WRITE` handlers.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/7afba9221f70d4cbce0f417c558879cba0eb5e66; https://git.kernel.org/stable/c/842f307a1d115b24f2bcb2415c4e344f11f55930; https://git.kernel.org/stable/c/92352ed2f9ac422181e381c2430c2d0dfb46faa0
CVE: CVE-2025-39687
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: light: as73211: Ensure buffer holes are zeroed

Given that the buffer is copied to a kfifo that ultimately user space
can read, ensure we zero it.
CVSS Score: 7.1 (HIGH)
References: https://git.kernel.org/stable/c/433b99e922943efdfd62b9a8e3ad[PII_REDACTED]f2; https://git.kernel.org/stable/c/83f14c4ca1ad78fcfb3e0de07d6d8a0c59550fc2; https://git.kernel.org/stable/c/8acd9a0eaa8c9a28e385c0a6a56bb821cb549771
CVE: CVE-2025-39689
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

ftrace: Also allocate and copy hash for reading of filter files

Currently the reader of set_ftrace_filter and set_ftrace_notrace just adds
the pointer to the global tracer hash to its iterator. Unlike the writer
that allocates a copy of the hash, the reader keeps the pointer to the
filter hashes. This is problematic because this pointer is static across
function calls that release the locks that can update the global tracer
hashes. This can cause UAF and similar bugs.

Allocate and copy the hash for reading the filter files like it is done
for the writers. This not only fixes UAF bugs, but also makes the code a
bit simpler as it doesn't have to differentiate when to free the
iterator's hash between writers and readers.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/12064e1880fc9202be75ff668205b1703d92f74f; https://git.kernel.org/stable/c/3b114a3282ab1a12cb4618a8f45db5d7185e784a; https://git.kernel.org/stable/c/64db338140d2bad99a0a8c6a118dd60b3e1fb8cb
CVE: CVE-2025-39690
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: accel: sca3300: fix uninitialized iio scan data

Fix potential leak of uninitialized stack data to userspace by ensuring
that the `channels` array is zeroed before use.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/4e5b705cc6147f0b9173c6219079f41416bdd3c0; https://git.kernel.org/stable/c/c88c04adb8611e436e1e773fd5db3f8d7397d089
CVE: CVE-2025-39691
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/buffer: fix use-after-free when call bh_read() helper

There's issue as follows:
BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110
Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0
CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
 <IRQ>
 dump_stack_lvl+0x55/0x70
 print_address_description.constprop.0+0x2c/0x390
 print_report+0xb4/0x270
 kasan_report+0xb8/0xf0
 end_buffer_read_sync+0xe3/0x110
 end_bio_bh_io_sync+0x56/0x80
 blk_update_request+0x30a/0x720
 scsi_end_request+0x51/0x2b0
 scsi_io_completion+0xe3/0x480
 ? scsi_device_unbusy+0x11e/0x160
 blk_complete_reqs+0x7b/0x90
 handle_softirqs+0xef/0x370
 irq_exit_rcu+0xa5/0xd0
 sysvec_apic_timer_interrupt+0x6e/0x90
 </IRQ>

 Above issue happens when do ntfs3 filesystem mount, issue may happens
 as follows:
           mount                            IRQ
ntfs_fill_super
  read_cache_page
    do_read_cache_folio
      filemap_read_folio
        mpage_read_folio
	 do_mpage_readpage
	  ntfs_get_block_vbo
	   bh_read
	     submit_bh
	     wait_on_buffer(bh);
	                            blk_complete_reqs
				     scsi_io_completion
				      scsi_end_request
				       blk_update_request
				        end_bio_bh_io_sync
					 end_buffer_read_sync
					  __end_buffer_read_notouch
					   unlock_buffer

            wait_on_buffer(bh);--> return will return to caller

					  put_bh
					    --> trigger stack-out-of-bounds
In the mpage_read_folio() function, the stack variable 'map_bh' is
passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and
wait_on_buffer() returns to continue processing, the stack variable
is likely to be reclaimed. Consequently, during the end_buffer_read_sync()
process, calling put_bh() may result in stack overrun.

If the bh is not allocated on the stack, it belongs to a folio.  Freeing
a buffer head which belongs to a folio is done by drop_buffers() which
will fail to free buffers which are still locked.  So it is safe to call
put_bh() before __end_buffer_read_notouch().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/03b40bf5d0389ca23ae6857ee25789f0e0b47ce8; https://git.kernel.org/stable/c/042cf48ecf67f72c8b3846c7fac678f472712ff3; https://git.kernel.org/stable/c/3169edb8945c295cf89120fc6b2c35cfe3ad4c9e
CVE: CVE-2025-39692
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy()

We can't call destroy_workqueue(smb_direct_wq); before stop_sessions()!

Otherwise already existing connections try to use smb_direct_wq as
a NULL pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/003e6a3150299f681f34cb189aa068018cef6a45; https://git.kernel.org/stable/c/212eb86f75b4d7b82f3d94aed95ba61103bccb93; https://git.kernel.org/stable/c/524e90e58a267dad11e23351d9e4b1f941490976
CVE: CVE-2025-39693
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Avoid a NULL pointer dereference

[WHY]
Although unlikely drm_atomic_get_new_connector_state() or
drm_atomic_get_old_connector_state() can return NULL.

[HOW]
Check returns before dereference.

(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/07b93a5704b0b72002f0c4bd1076214af67dc661; https://git.kernel.org/stable/c/0c1a486cbe6f9cb194e3c4a8ade4af2a642ba165; https://git.kernel.org/stable/c/36a6b43573d152736eaf2557fe60580dd73e9350
CVE: CVE-2025-39694
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/sclp: Fix SCCB present check

Tracing code called by the SCLP interrupt handler contains early exits
if the SCCB address associated with an interrupt is NULL. This check is
performed after physical to virtual address translation.

If the kernel identity mapping does not start at address zero, the
resulting virtual address is never zero, so that the NULL checks won't
work. Subsequently this may result in incorrect accesses to the first
page of the identity mapping.

Fix this by introducing a function that handles the NULL case before
address translation.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/430fa71027b6ac9bb0ce5532b8d0676777d4219a; https://git.kernel.org/stable/c/61605c847599fbfdfafe638607841c7d73719081; https://git.kernel.org/stable/c/86c2825791c3836a8f77a954b9c5ebe6fab410c5
CVE: CVE-2025-39695
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Flush delayed SKBs while releasing RXE resources

When skb packets are sent out, these skb packets still depends on
the rxe resources, for example, QP, sk, when these packets are
destroyed.

If these rxe resources are released when the skb packets are destroyed,
the call traces will appear.

To avoid skb packets hang too long time in some network devices,
a timestamp is added when these skb packets are created. If these
skb packets hang too long time in network devices, these network
devices can free these skb packets to release rxe resources.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3c3e9a9f2972b364e8c2cfbfdeb23c6d6be4f87f; https://git.kernel.org/stable/c/732d4bd7b78a2752ad43cc39287ef41893c5eee2; https://git.kernel.org/stable/c/8ead139a8edef485cc36d3a792e2ae5dd538339a
CVE: CVE-2025-39696
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: hda: tas2781: Fix wrong reference of tasdevice_priv

During the conversion to unify the calibration data management, the
reference to tasdevice_priv was wrongly set to h->hda_priv instead of
h->priv.  This resulted in memory corruption and crashes eventually.
Unfortunately it's a void pointer, hence the compiler couldn't know
that it's wrong.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2812815aa79637d39d4398ecd7e58f65d1c79231; https://git.kernel.org/stable/c/3f4422e7c9436abf81a00270be7e4d6d3760ec0e
CVE: CVE-2025-39697
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

NFS: Fix a race when updating an existing write

After nfs_lock_and_join_requests() tests for whether the request is
still attached to the mapping, nothing prevents a call to
nfs_inode_remove_request() from succeeding until we actually lock the
page group.
The reason is that whoever called nfs_inode_remove_request() doesn't
necessarily have a lock on the page group head.

So in order to avoid races, let's take the page group lock earlier in
nfs_lock_and_join_requests(), and hold it across the removal of the
request in nfs_inode_remove_request().
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0ff42a32784e0f2cb46a46da8e9f473538c13e1b; https://git.kernel.org/stable/c/181feb41f0b268e6288bf9a7b984624d7fe2031d; https://git.kernel.org/stable/c/202a3432d21ac060629a760fff3b0a39859da3ea
CVE: CVE-2025-39698
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

io_uring/futex: ensure io_futex_wait() cleans up properly on failure

The io_futex_data is allocated upfront and assigned to the io_kiocb
async_data field, but the request isn't marked with REQ_F_ASYNC_DATA
at that point. Those two should always go together, as the flag tells
io_uring whether the field is valid or not.

Additionally, on failure cleanup, the futex handler frees the data but
does not clear ->async_data. Clear the data and the flag in the error
path as well.

Thanks to Trend Micro Zero Day Initiative and particularly ReDress for
reporting this.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416, CWE-672
References: https://git.kernel.org/stable/c/508c1314b342b78591f51c4b5dadee31a88335df; https://git.kernel.org/stable/c/d34c04152df517c59979b4bf2a47f491e06d3256; https://git.kernel.org/stable/c/d9f93172820a53ab42c4b0e5e65291f4f9d00ad2
CVE: CVE-2025-39699
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/riscv: prevent NULL deref in iova_to_phys

The riscv_iommu_pte_fetch() function returns either NULL for
unmapped/never-mapped iova, or a valid leaf pte pointer that
requires no further validation.

riscv_iommu_iova_to_phys() failed to handle NULL returns.
Prevent null pointer dereference in
riscv_iommu_iova_to_phys(), and remove the pte validation.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/220c491490255b656672bb572b18460cd9155926; https://git.kernel.org/stable/c/99d4d1a070870aa08163af8ce0522992b7f35d8c
CVE: CVE-2025-39700
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/damon/ops-common: ignore migration request to invalid nodes

damon_migrate_pages() tries migration even if the target node is invalid. 
If users mistakenly make such invalid requests via
DAMOS_MIGRATE_{HOT,COLD} action, the below kernel BUG can happen.

    [ 7831.883495] BUG: unable to handle page fault for address:[PII_REDACTED]001f48
    [ 7831.884160] #PF: supervisor read access in kernel mode
    [ 7831.884681] #PF: error_code(0x0000) - not-present page
    [ 7831.885203] PGD 0 P4D 0
    [ 7831.885468] Oops: Oops: 0000 [#1] SMP PTI
    [ 7831.885852] CPU: 31 UID: 0 PID: 94202 Comm: kdamond.0 Not tainted 6.16.0-rc5-mm-new-damon+ #93 PREEMPT(voluntary)
    [ 7831.886913] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.el9 04/01/2014
    [ 7831.887777] RIP: 0010:__alloc_frozen_pages_noprof (include/linux/mmzone.h:1724 include/linux/mmzone.h:1750 mm/page_alloc.c:4936 mm/page_alloc.c:5137)
    [...]
    [ 7831.895953] Call Trace:
    [ 7831.896195]  <TASK>
    [ 7831.896397] __folio_alloc_noprof (mm/page_alloc.c:5183 mm/page_alloc.c:5192)
    [ 7831.896787] migrate_pages_batch (mm/migrate.c:1189 mm/migrate.c:1851)
    [ 7831.897228] ? __pfx_alloc_migration_target (mm/migrate.c:2137)
    [ 7831.897735] migrate_pages (mm/migrate.c:2078)
    [ 7831.898141] ? __pfx_alloc_migration_target (mm/migrate.c:2137)
    [ 7831.898664] damon_migrate_folio_list (mm/damon/ops-common.c:321 mm/damon/ops-common.c:354)
    [ 7831.899140] damon_migrate_pages (mm/damon/ops-common.c:405)
    [...]

Add a target node validity check in damon_migrate_pages().  The validity
check is stolen from that of do_pages_move(), which is being used for the
move_pages() system call.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-1284
References: https://git.kernel.org/stable/c/7c303fa1f311aadc17fa82b7bbf776412adf45de; https://git.kernel.org/stable/c/7e6c3130690a01076efdf45aa02ba5d5c16849a0; https://git.kernel.org/stable/c/9d0c2d15aff96746f99a7c97221bb8ce5b62db19
CVE: CVE-2025-39701
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: pfr_update: Fix the driver update version check

The security-version-number check should be used rather
than the runtime version check for driver updates.

Otherwise, the firmware update would fail when the update binary had
a lower runtime version number than the current one.

[ rjw: Changelog edits ]
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/79300ff532bccbbf654992c7c0863b49a6c3973c; https://git.kernel.org/stable/c/8151320c747efb22d30b035af989fed0d502176e; https://git.kernel.org/stable/c/908094681f645d3a78e18ef90561a97029e2df7b
CVE: CVE-2025-39702
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6: sr: Fix MAC comparison to be constant-time

To prevent timing attacks, MACs need to be compared in constant time.
Use the appropriate helper function for this.
CVSS Score: 7.0 (HIGH)
CWE: CWE-203
References: https://git.kernel.org/stable/c/3b348c9c8d2ca2c67559ffd0e258ae7e1107d4f0; https://git.kernel.org/stable/c/3ddd55cf19ed6cc62def5e3af10c2a9df1b861c3; https://git.kernel.org/stable/c/86b6d34717fe0570afce07ee79b8eeb40341f831
CVE: CVE-2025-39704
Published: 2025-09-05
Description: In the Linux kernel, the following vulnerability has been resolved:

LoongArch: KVM: Fix stack protector issue in send_ipi_data()

Function kvm_io_bus_read() is called in function send_ipi_data(), buffer
size of parameter *val should be at least 8 bytes. Since some emulation
functions like loongarch_ipi_readl() and kvm_eiointc_read() will write
the buffer *val with 8 bytes signed extension regardless parameter len.

Otherwise there will be buffer overflow issue when CONFIG_STACKPROTECTOR
is enabled. The bug report is shown as follows:

Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: send_ipi_data+0x194/0x1a0 [kvm]
CPU: 11 UID: 107 PID: 2692 Comm: CPU 0/KVM Not tainted 6.17.0-rc1+ #102 PREEMPT(full)
Stack : [PII_REDACTED] [PII_REDACTED][PII_REDACTED]af371c 900000013c68c000
        900000013c68f[PII_REDACTED]13c68f858 [PII_REDACTED] 900000013c68f998
        900000013c68f[PII_REDACTED]13c68f[PII_REDACTED]13c68f6c0 fffffffffffdb058
        fffffffffffdb0e0 900000013c68f858 911e1d4d39cf0ec2[PII_REDACTED]657a00
        [PII_REDACTED] fffffffffffffffe [PII_REDACTED][PII_REDACTED]55206e
        6f73676e6f6f4c20 [PII_REDACTED][PII_REDACTED]6b4000 [PII_REDACTED]
        [PII_REDACTED] [PII_REDACTED] [PII_REDACTED][PII_REDACTED]8f9000
        900000013c68fa68 900000013c68fab4[PII_REDACTED]9279f0[PII_REDACTED]53f940
       [PII_REDACTED]01f360 [PII_REDACTED][PII_REDACTED]af3[PII_REDACTED]04390000c
       [PII_REDACTED]0000b0 [PII_REDACTED] [PII_REDACTED][PII_REDACTED]071c1d
        ...
Call Trace:
[<[PII_REDACTED]af3734>] show_stack+0x5c/0x180
[<[PII_REDACTED]aed168>] dump_stack_lvl+0x6c/0x9c
[<[PII_REDACTED]ad0ab0>] vpanic+0x108/0x2c4
[<[PII_REDACTED]ad0ca8>] panic+0x3c/0x40
[<[PII_REDACTED]eb0a1c>] __stack_chk_fail+0x14/0x18
[<ffff[PII_REDACTED]f8>] send_ipi_data+0x190/0x1a0 [kvm]
[<ffff[PII_REDACTED]e4>] __kvm_io_bus_write+0xa4/0xe8 [kvm]
[<ffff[PII_REDACTED]7c>] kvm_io_bus_write+0x54/0x90 [kvm]
[<ffff80000233f9f8>] kvm_emu_iocsr+0x180/0x310 [kvm]
[<ffff80000233fe08>] kvm_handle_gspr+0x280/0x478 [kvm]
[<ffff[PII_REDACTED]e8>] kvm_handle_exit+0xc0/0x130 [kvm]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-674
References: https://git.kernel.org/stable/c/5c68549c81bcca70fc464e305ffeefd9af968287; https://git.kernel.org/stable/c/b5b49d341f90eed6de794b6ff34ad3dd66d34343