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

platform/x86: think-lmi: Fix memory leak when showing current settings

When retriving a item string with tlmi_setting(), the result has to be
freed using kfree(). In current_value_show() however, malformed
item strings are not freed, causing a memory leak.
Fix this by eliminating the early return responsible for this.
References: https://git.kernel.org/stable/c/5f99014c19fa50a5719c0bb[PII_REDACTED]2675893; https://git.kernel.org/stable/c/9071525bfcb1f5674117dbed3eca0cd7b122813b; https://git.kernel.org/stable/c/a3c4c053014585dcf20f4df954791b74d8a8afcd
CVE: CVE-2023-53832
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

md/raid10: fix null-ptr-deref in raid10_sync_request

init_resync() inits mempool and sets conf->have_replacemnt at the beginning
of sync, close_sync() frees the mempool when sync is completed.

After [1] recovery might be skipped and init_resync() is called but
close_sync() is not. null-ptr-deref occurs with r10bio->dev[i].repl_bio.

The following is one way to reproduce the issue.

  1) create a array, wait for resync to complete, mddev->recovery_cp is set
     to MaxSector.
  2) recovery is woken and it is skipped. conf->have_replacement is set to
     0 in init_resync(). close_sync() not called.
  3) some io errors and rdev A is set to WantReplacement.
  4) a new device is added and set to A's replacement.
  5) recovery is woken, A have replacement, but conf->have_replacemnt is
     0. r10bio->dev[i].repl_bio will not be alloced and null-ptr-deref
     occurs.

Fix it by not calling init_resync() if recovery skipped.

[1] commit 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled")
References: https://git.kernel.org/stable/c/14964127be[PII_REDACTED]6a392c9faa9ebaabbbe1; https://git.kernel.org/stable/c/38d[PII_REDACTED]6840b49fd1dcac9aedfd14a9d42; https://git.kernel.org/stable/c/[PII_REDACTED]7e3de9d3e94e09238ace2b6f246446
CVE: CVE-2023-53833
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915: Fix NULL ptr deref by checking new_crtc_state

intel_atomic_get_new_crtc_state can return NULL, unless crtc state wasn't
obtained previously with intel_atomic_get_crtc_state, so we must check it
for NULLness here, just as in many other places, where we can't guarantee
that intel_atomic_get_crtc_state was called.
We are currently getting NULL ptr deref because of that, so this fix was
confirmed to help.

(cherry picked from commit 1d5b09f8daf859247a1ea65b0d732a24d88980d8)
References: https://git.kernel.org/stable/c/8b3c0d2d1685ba40b0af4ee1f8d8824a73870f88; https://git.kernel.org/stable/c/a41d985902c153c31c616fe183cf2ee331e95ecb; https://git.kernel.org/stable/c/dbf25cc21beff4fd2e730573845a266504b21bb2
CVE: CVE-2023-53834
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: adc: ina2xx: avoid NULL pointer dereference on OF device match

The affected lines were resulting in a NULL pointer dereference on our
platform because the device tree contained the following list of
compatible strings:

    power-sensor@40 {
        compatible = "ti,ina232", "ti,ina231";
        ...
    };

Since the driver doesn't declare a compatible string "ti,ina232", the OF
matching succeeds on "ti,ina231". But the I2C device ID info is
populated via the first compatible string, cf. modalias population in
of_i2c_get_board_info(). Since there is no "ina232" entry in the legacy
I2C device ID table either, the struct i2c_device_id *id pointer in the
probe function is NULL.

Fix this by using the already populated type variable instead, which
points to the proper driver data. Since the name is also wanted, add a
generic one to the ina2xx_config table.
References: https://git.kernel.org/stable/c/13f3ce53b65aa8b44cad7039d31e62c9ffd6c5d1; https://git.kernel.org/stable/c/77b689cc27d489b75d33f1a368356d70eb0ce08c; https://git.kernel.org/stable/c/a41e19cc0d6b6a445a4133170b90271e4a2553dc
CVE: CVE-2023-53835
Published: 2025-12-09
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2023-53837
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm: fix NULL-deref on snapshot tear down

In case of early initialisation errors and on platforms that do not use
the DPU controller, the deinitilisation code can be called with the kms
pointer set to NULL.

Patchwork: https://patchwork.freedesktop.org/patch/525099/
References: https://git.kernel.org/stable/c/16e0e6fb4511c004a5a0987d5bd75d9bcfb2b175; https://git.kernel.org/stable/c/19fe79ae816a7e3400df1eb4d27530bf9b8ae258; https://git.kernel.org/stable/c/8eca32b5b92a0be956a8934d7eddf4f70c107927
CVE: CVE-2023-53838
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: synchronize atomic write aborts

To fix a race condition between atomic write aborts, I use the inode
lock and make COW inode to be re-usable thoroughout the whole
atomic file inode lifetime.
References: https://git.kernel.org/stable/c/102b82708c1523b36d421cb[PII_REDACTED]069bc17; https://git.kernel.org/stable/c/a46bebd502fe1a3bd1d22f64cedd93e7e7702693; https://git.kernel.org/stable/c/b[PII_REDACTED]642099cec907f54f42e55f5325453
CVE: CVE-2023-53839
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

dccp: fix data-race around dp->dccps_mss_cache

dccp_sendmsg() reads dp->dccps_mss_cache before locking the socket.
Same thing in do_dccp_getsockopt().

Add READ_ONCE()/WRITE_ONCE() annotations,
and change dccp_sendmsg() to check again dccps_mss_cache
after socket is locked.
References: https://git.kernel.org/stable/c/162fa1e3cfb62aa780d7c40c8cccb6c2f8bef7c1; https://git.kernel.org/stable/c/2bdc7f272b3a110a4e1fdee6c47c8d20f9b20817; https://git.kernel.org/stable/c/67eebc7a9217f999b779d46fba5312a716f0dc1d
CVE: CVE-2023-53840
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: early: xhci-dbc: Fix a potential out-of-bound memory access

If xdbc_bulk_write() fails, the values in 'buf' can be anything. So the
string is not guaranteed to be NULL terminated when xdbc_trace() is called.

Reserve an extra byte, which will be zeroed automatically because 'buf' is
a static variable, in order to avoid troubles, should it happen.
References: https://git.kernel.org/stable/c/351c8d8650d1ccc006255fa01f98b6c6496a02e5; https://git.kernel.org/stable/c/a4a97ab3db5c081eb6e7dba91306adefb461e0bd; https://git.kernel.org/stable/c/df7c8aba7309f4dc55df94e06b67f576c0f52406
CVE: CVE-2023-53842
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: codecs: wcd-mbhc-v2: fix resource leaks on component remove

The MBHC resources must be released on component probe failure and
removal so can not be tied to the lifetime of the component device.

This is specifically needed to allow probe deferrals of the sound card
which otherwise fails when reprobing the codec component:

    snd-sc8280xp sound: ASoC: failed to instantiate card -517
    genirq: Flags mismatch irq 299. 00002001 (mbhc sw intr) vs. 00002001 (mbhc sw intr)
    wcd938x_codec audio-codec: Failed to request mbhc interrupts -16
    wcd938x_codec audio-codec: mbhc initialization failed
    wcd938x_codec audio-codec: ASoC: error at snd_soc_component_probe on audio-codec: -16
    snd-sc8280xp sound: ASoC: failed to instantiate card -16
References: https://git.kernel.org/stable/c/17feff71d06c96dea1fa72451c20d411e9d5ac8f; https://git.kernel.org/stable/c/90ab6446eb522e31421b77bf8f45714f5668f9a3; https://git.kernel.org/stable/c/a5475829adcc600bc69ee9ff7c9e3e43fb4f8d30
CVE: CVE-2023-53843
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

net: openvswitch: reject negative ifindex

Recent changes in net-next (commit 759ab1edb56c ("net: store netdevs
in an xarray")) refactored the handling of pre-assigned ifindexes
and let syzbot surface a latent problem in ovs. ovs does not validate
ifindex, making it possible to create netdev ports with negative
ifindex values. It's easy to repro with YNL:

$ ./cli.py --spec netlink/specs/ovs_datapath.yaml \
         --do new \
	 --json '{"upcall-pid": 1, "name":"my-dp"}'
$ ./cli.py --spec netlink/specs/ovs_vport.yaml \
	 --do new \
	 --json '{"upcall-pid": "00000001", "name": "some-port0", "dp-ifindex":3,"ifindex":[PII_REDACTED],"type":2}'

$ ip link show
-65536: some-port0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 7a:48:21:ad:0b:fb brd ff:ff:ff:ff:ff:ff
...

Validate the inputs. Now the second command correctly returns:

$ ./cli.py --spec netlink/specs/ovs_vport.yaml \
	 --do new \
	 --json '{"upcall-pid": "00000001", "name": "some-port0", "dp-ifindex":3,"ifindex":[PII_REDACTED],"type":2}'

lib.ynl.NlError: Netlink error: Numerical result out of range
nl_len = 108 (92) nl_flags = 0x300 nl_type = 2
	error: -34	extack: {'msg': 'integer out of range', 'unknown': [[type:4 len:36] b'\x0c\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0c\x00\x03\x00\xff\xff\xff\x7f\x00\x00\x00\x00\x08\x00\x01\x00\x08\x00\x00\x00'], 'bad-attr': '.ifindex'}

Accept 0 since it used to be silently ignored.
References: https://git.kernel.org/stable/c/881faff9e548a7ddfb11595be7c1c649217d27db; https://git.kernel.org/stable/c/a552bfa16bab4ce901ee721346a28c4e483f4066; https://git.kernel.org/stable/c/c965a58376146dcfdda186819462e8eb3aadef3a
CVE: CVE-2023-53844
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/ttm: Don't leak a resource on swapout move error

If moving the bo to system for swapout failed, we were leaking
a resource. Fix.
References: https://git.kernel.org/stable/c/4a5b37ea6797d7a53e6dd004aa37e149f40199ce; https://git.kernel.org/stable/c/a590f03d8de7c4cb7ce4916dc7f2fd10711faabe; https://git.kernel.org/stable/c/af4e0ce2af8a8f0ff3b89702a1e18d8ec2c4a834
CVE: CVE-2023-53845
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

nilfs2: fix infinite loop in nilfs_mdt_get_block()

If the disk image that nilfs2 mounts is corrupted and a virtual block
address obtained by block lookup for a metadata file is invalid,
nilfs_bmap_lookup_at_level() may return the same internal return code as
-ENOENT, meaning the block does not exist in the metadata file.

This duplication of return codes confuses nilfs_mdt_get_block(), causing
it to read and create a metadata block indefinitely.

In particular, if this happens to the inode metadata file, ifile,
semaphore i_rwsem can be left held, causing task hangs in lock_mount.

Fix this issue by making nilfs_bmap_lookup_at_level() treat virtual block
address translation failures with -ENOENT as metadata corruption instead
of returning the error code.
References: https://git.kernel.org/stable/c/25457d07c8146e57d28906c663def033dc425af6; https://git.kernel.org/stable/c/34c5f17222b50c79848bb03ec[PII_REDACTED]e6a45; https://git.kernel.org/stable/c/5b29661669cb65b9750a3cf70ed3eaf947b92167
CVE: CVE-2023-53846
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to do sanity check on direct node in truncate_dnode()

syzbot reports below bug:

BUG: KASAN: slab-use-after-free in f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574
Read of size 4 at addr ffff88802a25c000 by task syz-executor148/5000

CPU: 1 PID: 5000 Comm: syz-executor148 Not tainted 6.4.0-rc7-syzkaller-00041-ge660abd551f1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351
 print_report mm/kasan/report.c:462 [inline]
 kasan_report+0x11c/0x130 mm/kasan/report.c:572
 f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574
 truncate_dnode+0x229/0x2e0 fs/f2fs/node.c:944
 f2fs_truncate_inode_blocks+0x64b/0xde0 fs/f2fs/node.c:1154
 f2fs_do_truncate_blocks+0x4ac/0xf30 fs/f2fs/file.c:721
 f2fs_truncate_blocks+0x7b/0x300 fs/f2fs/file.c:749
 f2fs_truncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799
 f2fs_truncate include/linux/fs.h:825 [inline]
 f2fs_setattr+0x1738/0x2090 fs/f2fs/file.c:1006
 notify_change+0xb2c/0x1180 fs/attr.c:483
 do_truncate+0x143/0x200 fs/open.c:66
 handle_truncate fs/namei.c:3295 [inline]
 do_open fs/namei.c:3640 [inline]
 path_openat+0x2083/0x2750 fs/namei.c:3791
 do_filp_open+0x1ba/0x410 fs/namei.c:3818
 do_sys_openat2+0x16d/0x4c0 fs/open.c:1356
 do_sys_open fs/open.c:1372 [inline]
 __do_sys_creat fs/open.c:1448 [inline]
 __se_sys_creat fs/open.c:1442 [inline]
 __x64_sys_creat+0xcd/0x120 fs/open.c:1442
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The root cause is, inodeA references inodeB via inodeB's ino, once inodeA
is truncated, it calls truncate_dnode() to truncate data blocks in inodeB's
node page, it traverse mapping data from node->i.i_addr[0] to
node->i.i_addr[ADDRS_PER_BLOCK() - 1], result in out-of-boundary access.

This patch fixes to add sanity check on dnode page in truncate_dnode(),
so that, it can help to avoid triggering such issue, and once it encounters
such issue, it will record newly introduced ERROR_INVALID_NODE_REFERENCE
error into superblock, later fsck can detect such issue and try repairing.

Also, it removes f2fs_truncate_data_blocks() for cleanup due to the
function has only one caller, and uses f2fs_truncate_data_blocks_range()
instead.
References: https://git.kernel.org/stable/c/a6ec83786ab9f13f25fb18166dee908845713a95; https://git.kernel.org/stable/c/af0f716ad3b039cab9d426da63a5ee6c88751185
CVE: CVE-2023-53847
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

usb-storage: alauda: Fix uninit-value in alauda_check_media()

Syzbot got KMSAN to complain about access to an uninitialized value in
the alauda subdriver of usb-storage:

BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0
drivers/usb/storage/alauda.c:1137
CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x191/0x1f0 lib/dump_stack.c:113
  kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108
  __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250
  alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460

The problem is that alauda_check_media() doesn't verify that its USB
transfer succeeded before trying to use the received data.  What
should happen if the transfer fails isn't entirely clear, but a
reasonably conservative approach is to pretend that no media is
present.

A similar problem exists in a usb_stor_dbg() call in
alauda_get_media_status().  In this case, when an error occurs the
call is redundant, because usb_stor_ctrl_transfer() already will print
a debugging message.

Finally, unrelated to the uninitialized memory access, is the fact
that alauda_check_media() performs DMA to a buffer on the stack.
Fortunately usb-storage provides a general purpose DMA-able buffer for
uses like this.  We'll use it instead.
References: https://git.kernel.org/stable/c/044f4446e06bb03c52216697b14867ebc555ad3b; https://git.kernel.org/stable/c/0d2d5282d39aed6f27dfe1ed60a5f3934ebd21cd; https://git.kernel.org/stable/c/153c3e85873cc3e2f387169783c3a227bad9a95a
CVE: CVE-2023-53848
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

md/raid5-cache: fix a deadlock in r5l_exit_log()

Commit b13015af94cf ("md/raid5-cache: Clear conf->log after finishing
work") introduce a new problem:

// caller hold reconfig_mutex
r5l_exit_log
 flush_work(&log->disable_writeback_work)
			r5c_disable_writeback_async
			 wait_event
			  /*
			   * conf->log is not NULL, and mddev_trylock()
			   * will fail, wait_event() can never pass.
			   */
 conf->log = NULL

Fix this problem by setting 'config->log' to NULL before wake_up() as it
used to be, so that wait_event() from r5c_disable_writeback_async() can
exist. In the meantime, move forward md_unregister_thread() so that
null-ptr-deref this commit fixed can still be fixed.
References: https://git.kernel.org/stable/c/71cf23271f015a57038bdc[PII_REDACTED]f9fe5500; https://git.kernel.org/stable/c/a705b11b358dee677aad80630e7608b2d5f56691; https://git.kernel.org/stable/c/ac9e103f282a7854f3274ef5ff0742fbbe8d7d6b
CVE: CVE-2023-53849
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm: fix workqueue leak on bind errors

Make sure to destroy the workqueue also in case of early errors during
bind (e.g. a subcomponent failing to bind).

Since commit c3b790ea07a1 ("drm: Manage drm_mode_config_init with
drmm_") the mode config will be freed when the drm device is released
also when using the legacy interface, but add an explicit cleanup for
consistency and to facilitate backporting.

Patchwork: https://patchwork.freedesktop.org/patch/525093/
References: https://git.kernel.org/stable/c/28e34db2f3e0130872e2384dd9df9f82bd89e967; https://git.kernel.org/stable/c/6e1476225ec02eeebc4b79f793506f80bc4bca8f; https://git.kernel.org/stable/c/8551c4b7c8ffb42f759547e5c39da5980abf2432
CVE: CVE-2023-53850
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

iavf: use internal state to free traffic IRQs

If the system tries to close the netdev while iavf_reset_task() is
running, __LINK_STATE_START will be cleared and netif_running() will
return false in iavf_reinit_interrupt_scheme(). This will result in
iavf_free_traffic_irqs() not being called and a leak as follows:

    [7632.489326] remove_proc_entry: removing non-empty directory 'irq/999', leaking at least 'iavf-enp24s0f0v0-TxRx-0'
    [7632.490214] WARNING: CPU: 0 PID: 10 at fs/proc/generic.c:718 remove_proc_entry+0x19b/0x1b0

is shown when pci_disable_msix() is later called. Fix by using the
internal adapter state. The traffic IRQs will always exist if
state == __IAVF_RUNNING.
References: https://git.kernel.org/stable/c/5e9db32eec628481f5da97a5b1aedb84a5240d18; https://git.kernel.org/stable/c/6d9d01689b82ff5cb8f8d2a82717d7997bc0bfff; https://git.kernel.org/stable/c/a77ed5c5b768e9649be240a2d864e5cd9c6a2015
CVE: CVE-2023-53851
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm/dp: Drop aux devices together with DP controller

Using devres to depopulate the aux bus made sure that upon a probe
deferral the EDP panel device would be destroyed and recreated upon next
attempt.

But the struct device which the devres is tied to is the DPUs
(drm_dev->dev), which may be happen after the DP controller is torn
down.

Indications of this can be seen in the commonly seen EDID-hexdump full
of zeros in the log, or the occasional/rare KASAN fault where the
panel's attempt to read the EDID information causes a use after free on
DP resources.

It's tempting to move the devres to the DP controller's struct device,
but the resources used by the device(s) on the aux bus are explicitly
torn down in the error path. The KASAN-reported use-after-free also
remains, as the DP aux "module" explicitly frees its devres-allocated
memory in this code path.

As such, explicitly depopulate the aux bus in the error path, and in the
component unbind path, to avoid these issues.

Patchwork: https://patchwork.freedesktop.org/patch/542163/
References: https://git.kernel.org/stable/c/2fde37445807e6e6d7981402d0bf1be0e5d81291; https://git.kernel.org/stable/c/a7bfb2ad2184a1fba78be35209b6019aa8cc8d4d; https://git.kernel.org/stable/c/e09ed06938807cb113cddd0708ed74bd8cdaff33
CVE: CVE-2023-53852
Published: 2025-12-09
Description: In the Linux kernel, the following vulnerability has been resolved:

nvme-core: fix memory leak in dhchap_secret_store

Free dhchap_secret in nvme_ctrl_dhchap_secret_store() before we return
fix following kmemleack:-

unreferenced object 0xffff8886376ea800 (size 64):
  comm "check", pid 22048, jiffies[PII_REDACTED] (age 92.199s)
  hex dump (first 32 bytes):
    44 48 48 43 2d 31 3a 30 30 3a 6e 78 72 35 4b 67  DHHC-1:00:nxr5Kg
    75 58 34 75 6f 41 78 73 4a 61 34 63 2f 68 75 4c  uX4uoAxsJa4c/huL
  backtrace:
    [<[PII_REDACTED]ce5d4b>] __kmalloc+0x4b/0x130
    [<000000009be1cdc1>] nvme_ctrl_dhchap_secret_store+0x8f/0x160 [nvme_core]
    [<00000000ac06c96a>] kernfs_fop_write_iter+0x12b/0x1c0
    [<[PII_REDACTED]7e7ced>] vfs_write+0x2ba/0x3c0
    [<00000000f9491baf>] ksys_write+0x5f/0xe0
    [<000000001c46513d>] do_syscall_64+0x3b/0x90
    [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
unreferenced object 0xffff8886376eaf00 (size 64):
  comm "check", pid 22048, jiffies[PII_REDACTED] (age 92.168s)
  hex dump (first 32 bytes):
    44 48 48 43 2d 31 3a 30 30 3a 6e 78 72 35 4b 67  DHHC-1:00:nxr5Kg
    75 58 34 75 6f 41 78 73 4a 61 34 63 2f 68 75 4c  uX4uoAxsJa4c/huL
  backtrace:
    [<[PII_REDACTED]ce5d4b>] __kmalloc+0x4b/0x130
    [<000000009be1cdc1>] nvme_ctrl_dhchap_secret_store+0x8f/0x160 [nvme_core]
    [<00000000ac06c96a>] kernfs_fop_write_iter+0x12b/0x1c0
    [<[PII_REDACTED]7e7ced>] vfs_write+0x2ba/0x3c0
    [<00000000f9491baf>] ksys_write+0x5f/0xe0
    [<000000001c46513d>] do_syscall_64+0x3b/0x90
    [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
References: https://git.kernel.org/stable/c/2e9b[PII_REDACTED]1d60fecf6bf1d2edc8dd0181d; https://git.kernel.org/stable/c/6a5eda[PII_REDACTED]ab82c5d56bcf784b8294e298; https://git.kernel.org/stable/c/a836ca33c5b07d34dd5347af9f64d25651d12674